









CALL FOR PAPERS 



IEEE Computer Society Conference on 

computer Vision and Pattern Recognition 

Sheraton Grand Hotel on Harbor island 
San Diego, California 
June 4-8,1989 


GENERAL CHAIR 

Professor Rama Chellappa 
Department of EE-Systems 
university of Southern California 
Los Angeles, CA 90089-0272 

PROGRAM COMMITTEE 

Chris Brown 
Larrv Davis 
Allen Hanson 
Robert Haralick 
Ellen Hildreth 


PROGRAM CO-CHAIRS 

professor Worthy Martin 
Department of Computer Science 
University of Virginia 
Charlottesville, VA 22903 


John Kearney 
Daryl Lawton 
Martin Levine 
David Lowe 
Gerard Medioni 


Professor John Kender 
Department of Computer Science 
Columbia University 
New York, NY 10027 


Theo Pavlidis 
Alex Pentland 
Roger Tsai 
John Tsotsos 
Jon Webb 


Anil Jain 
Ramesh Jain 
John Jarvis 
Avi Kak 

Rangaswamy Kashyap 


SUBMISSION OF PAPERS 

Four copies of complete di 

^e^ie”proces^Thedraftshould V indudea cover pa^e with a tittef authors'names, primary author^ 

address and telephone number, index terms containing at least one of the topics below. The cover page 
will be removed for the review process. The second page of the draft should contain only the title and 
an abstract of about 250 words. 

Authors will be notified of acceptance by February 1,1989 and final camera-ready papers, typed on special 
forms, will be required by March 8,1989. 


As a new feature there will be one or two video sessions, where authors can 
video tapes. For information regarding submission of video tapes for review 
John Kender at the address given above. 


present their work using 
purposes, please contact 


CONFERENCE TOPICS INCLUDE: 

• image Processing 

• 3-D Representation and 
Recognition 

• Motion 

• stereo 

• visual Navigation 


Shape from (shading, 
texture,...) 

Vision Systems and 
Architectures 
Pattern Recognition 
Applications of Computer Vision 


Al in Computer Vision 
Robust Statistical Methods for 
Computer Vision 
Neural Networks for 
Computer Vision 
Classifier systems 
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Unrealistic simplifications of analytical methods-costs 
and delays of programming 

Students see an animated telecommunication 
network-quick results, no programming 


Now for universities 
COMNET II.5 with animation 


New telecommunication network analysis teaching package 


Low cost to 
universities 


C OMNET II.5 simplifies your 
teaching of telecommunication 
network design and performance 
analysis by eliminating program¬ 
ming. 

Your students simply describe a 
network and its routing algorithms. 

Simulation follows immediately 
-no programming delays. 

Easy-to-understand results 

Your students get an animated 
picture of the network. Routing 
choices and changing levels of net¬ 
work utilization are apparent. 

Reports show blocking probabili¬ 
ties, call queueing and packet de¬ 
lays, network throughput, circuit 
group utilization, and circuit group 
queue statistics. 

Any network easily simulated 

Students can analyze any wide- 
area network which uses circuit 
switching, message switching, or 
packet switching. Virtual-circuit or 
datagram operation can be model¬ 
ed. 

Alternate-routing and adaptive 
shortest-path routing algorithms are 
built-in. 

With COMNET D.5 your 
students get results sooner and the 
results are better understood. 


We recognize the benefits of 
having our state-of-the-art systems 
used by the universities for research 
and teaching. 

For that reason we make the 
complete COMNET II.5® package 
available to universities for only a 
low distribution fee. 

Teachers are enthusiastic about 
COMNET II.5 because then- 
students can now solve complex 
analysis problems without the 
distraction of computer program¬ 
ming. You can focus on teaching 
telecommunication network design 
and analysis. 

The package includes COMNET 
II.5, training, support, complete 
documentation, and sample 
networks— everything you need. 

Act promptly—limited offer 

This offer is limited to 200 
universities. 

For immediate information 

Call Eric Chapman at (619) 
457-9681. In the UK, call Richard 
Eve on (01) 940-3606. 


COMNET II.5 results are 
realistic-the drastic simplifying 
assumptions required by analytical 
methods are eliminated. 

[ Rush information on the 
special telecommunication 
I network teaching package for 
| universities only. 

I Everything you need to teach 

telecommunication network analysis. 

I Also send information about: 

□ NETWORK II.5 for teaching computer 
network analysis and design. 

| □ SIMSCRIPT II.5 for teaching 

simulation modeling. 

□ SIMFACTORY-for teaching factory 
planning 







Return to: 

CACI University Offer 
3344 North Torrey Pines Court 
La Jolla, California 92037 

Or, better yet, call Eric Chapman at 
(619) 457-9681 
In the UK 

CACI 

26 The Quadrant 

Richmond, Surrey, England TW9 1DL 

Call Richard Eve on (01) 940-3606 


COMNET II.5, NETWORK II.J, SIMSCRIPT II.5, and 
SIMFACTORY are registered trademarks and service 
marks of CACI, INC. 
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ARTICLES 


\ J The Optical File Cabinet: 

A Random-Access File System for Write-Once Optical Disks 

Jason Gait 

The OFC exploits the favorable aspects of write-once optical disks while preserving the existing relationship between the operating 
system and the file system. 

23 Stepwise Refinement and Verification in Box-Structured Systems 

Harlan D. Mills 

Box structures of data abstractions allow the stepwise refinement and verification of hierarchical system designs from their specifi¬ 
cations at formal and informal levels. 

38 System and Application Software for the Armstrong Multiprocessor 

James T. Rayfield and Harvey F. Silverman 

Among the unique features of the Armstrong system are a reconfigurable I/O topology and extensive support for message passing. 

53 Traditional, Semantic, and Hyper-Semantic Approaches 
to Data Modeling 

Walter D. Potter and Robert P. Trueblood 

Data models define the formal structure of advanced information systems. Early models were computer oriented; more recent user- 
oriented approaches capture inferential relationships among real-world concepts. 

65 Programming in VS Fortran on the IBM 3090 
for Maximum Vector Performance 

Bowen Liu and Nelson Strother 

General programming techniques for hierarchical storage management can improve 3090 CPU performance up to three times 
and elapsed time performance up to twenty times for some vector codes. 
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IFIP CONGRESS '89 


XI a WORLD 

COMPUTER 

CONCUSS 




CONGRESS HIGHLIGHTS & 
FINAL CALL FOR PAPERS 

Sponsored by International Federation for 
Information Processing 

Hosted by American Federation of Information 
Processing Societies 

Organizing Committee Chair— Stephen S. Yau. USA 
Program Committee Chair— Herve Gallaire, FRG 


Congress: August 28-September 1,1989 
Exhibits: August 29-31,1989 
Tutorials: August 24-25,1989 
Technical Visits: August 25,29, and 31,1989 


The World Computer Congress is the premier 
assembly of computer professionals from around the 
globe. Held only every three years, and in the 
United States for the first time in twenty-four 
years, this prestigious event attracts top scientists, 
engineers, users, managers, and policy makers 
from industry, academia and governments. 


Ml 



v. 

Theme: Better Tools for Professionals 


The goal of this open scientific Congress is to identify emerging tools and 
explore how their benefits can be realized in a number of critical areas. 
The dynamic Congress agenda includes a broad based technical 
program, in-depth tutorials, and diverse technical visits to information 
processing facilities in the San Francisco area. Concurrent world 
computer exhibits showcase the very latest in software and hardware 
from manufacturers from around the globe. 

Moscone Center, San Francisco’s foremost meeting and exhibit hall, will 
house both the Technical Program and Exhibits. 


TECHNICAL PROGRAM _ 

The Technical Program will consist of eleven tracks, each of which will 
examine an area from various perspectives and address areas where 
significant scientific and technical changes are taking place. Each track, 
headed by the listed member of the Program Committee, will feature 
invited speakers and responders, panels and contributed papers from 
around the world. 

Fundamental Tools • Jozef Gruska, Czechoslovakia 

Languages and Operating • Gilles Kahn. France 
Systems 

Communication and • Otto Spaniol, FRG 
Distributed Systems 

Knowledge-Based Systems • John Mylopoulos, Canada 
Software Engineering • Mark Dowson, USA 
Supercomputing • Mario Tokoro, Japan 
VLSI-CAD Tools • Mario Barbacci, USA 
Office Automation • Bill Curtis, USA 
Factory Automation • Georges Giralt, France 

Education • D. Henk Wolbers, The Netherlands 
Computers and Society • Luis Penedo, Portugal 

Major Information • Dines Bjomer (Past Chair), 
Technology Programs Denmark 

Program Committee Chair • Herve Gallaire, FRG 
Organizing Committee Chair • Stephen Yau, USA 
Proceedings Editor • Gerhard Ritter, USA 


Final Call for Papers 

Contributions are sought for the Technical Program from all major 
Information Technology programs, national and international, public and 
private; IFIP Congress '89 will feature individual and comparative 
presentations evaluating and discussing software technology, computing 
and programming projects carefully selected to represent what these 
programs consider to be their best efforts. 

Papers must be original and high quality, fulfill the objectives of the 
Congress and fit one or more of the program tracks. Papers should have a 
broad scope, and not discuss narrow and isolated topics. All submitted 
papers will be reviewed for their significance, originality and clarity. 













































| ACCOMMODATIONS. TRAVEL AND TOURS 


Send six copies of the full paper (double spacel 3700-4500 words in 
English, including title, names, affiliations, addresses, and phone 
numbers of authors, the track the paper would fit, and a 150-word 
abstract, by November 1,1988, to: 


Program Committee Chair 

Herve Gallaire, ECRC 

Arabellastrasse 17 

D-8000 Munich 81 

Federal Republic of Germany 

Tel: 49-89-92 69 91 00 

Fax:49-89-92 69 91 70 

Telex: 52I69I0ECRC D 

e-mail: mcvaxlunidolecrcvaxlifip 

e-mail: ifip%eacvax.uucp@seismo.css.gov 

Authors of papers who wish to have system demonstrations of the results 
in their papers should submit a separate page proposal by November 1, 
1988. Notification of acceptance or rejection of papers and proposals will 
be mailed by February 15,1989. 


TUTORIALS _ 

Tutorials Chair—C.V. Ramamoorthy, USA 

To complement the broad based technical program, the following pre- 
Congress one-day tutorials will be provided on August 24th and 25th: 

Software Risk Analysis 

Barry Boehm, TRW Systems, Inc., Redondo Beach, California, USA 

Integrated Office Systems 

David Choy, IBM Research Lab, San lose, California, USA 

Human-Computer Interaction 

loelle Coutaz, IMAG, Grenoble Cedex, France, and Leonard Bass, 
Camegie-Mellon University, Pittsburgh, Pennsylvania, USA 
Computer Networks and Telematic Services 
Radu Popescu-Zeletin, Technical University of Berlin and 
GMC Research Center, Berlin, FRG 
Supercomputer Systems and Applications 
Paul B. Schneck, Supercomputing Research Center, 

Lanham, Maryland, USA 

Computers for Artificial Intelligence Applications 

Benjamin Wah, University of Illinois at Champaign-Urbana, USA 


TECHNICAL VISITS _ 

Technical Visits Chair—Sidney Fembach, USA 

San Francisco and the Silicon Valley, with one of the densest 
concentrations of computer research and manufacturing facilities in the 
world, offer unparalleled opportunities for attendees to see first-hand 
the American information processing industry. Technical visits to 
manufacturing facilities and research laboratories before and during the 
Congress supply a stimulating supplement to the technical program for 
Congress delegates. Site visits include: 

Amdahl Corporation 
Ampex Corporation 
Hewlett Packard Corporation 
IBM Corporation 

Lawrence Livermore National Laboratory 
NASA/Ames Research Center 
Silicon Graphics 


WORLD COMPUTER EXHIBITS _ 

A major exhibition of computer products, systems and services will take 
place in conjunction with the I Ith World Computer Congress. Housed in 
Moscone Center, exhibitors from around the world will display 
information processing equipment and services addressing a large 
number of critical areas. Exhibitors will have the unique opportunity to 
meet face to face with the top decision makers involved in the 
development and use of information technology. For more information, 
contact Industrial Presentations, Inc. 


Both charming and cosmopolitan, San Francisco treats visitors to majestic 
scenery, ethnic diversity, endless culinary possibilities and attractions 
such as the world-renowned Golden Gate Bridge. In addition, the San 
Francisco area is a major center of technological and entrepreneurial 
innovations in American high technology. 


ACCOMMODATIONS _ 

The Westin St. Francis Hotel, San Francisco's landmark hotel on Union 
Square, is the Congress headquarters hotel and will house most of the 
delegates. Also available through the Congress are a variety of other 
hotels in the heart of San Francisco to accommodate every budget. For 
information and reservations, contact Convention Service Center, Inc. 


TRAVEL _ 

United Airlines and Pan American Airlines are the official carriers for the 
I Ith World Computer Congress, offering special rates and arrangements 
for attendees. Air travel booking information will be available one year in 
advance of the Congress. 


SOCIAL PROGRAMS AND TOURS _ 

An extensive social and sightseeing program will help delegates and 
guests experience the excitement and beauty of San Francisco and the 
surrounding area. Wine tastings in the Napa Valley, cruises on the Bay, 
and drives along the beautiful Monterey Peninsula are just a few of the 
opportunities to explore the cultural, historic and scenic highlights of the 
San Francisco area. For information and reservations, contact Convention 
Service Center, Inc. 



Registration fees for Technical Program, in US dollars: 


Regular Fee 
Students 
Students without 
proceedings 
Each Tutorial 


May 2, '89 
Through Through 

May I,'89 )ulyl5,'89 

$330 $400 

$120 $150 

$ 75 $100 

$180 $220 


July 16, '89 
Through 
On-Site 

$450 

$200 

$150 

$260 


FOR ADDITIONAL INFORMATION _ 

For detailed information on the Congress, program, registration, tours 
and accommodations, contact: 

I Ith World Computer Congress 
Convention Service Center, Inc. 

P.O. Box 18-P 

Denver, Colorado 80218, USA 
Phone 13031831-6338 
telex: 168184SVCCTR UT 

Or outside North and Central America, you may contact your national 
computer society for more information. 

For information about exhibits contact: 

Exhibits Management 
Industrial Presentations, Inc. 

12371 East Cornell Ave. 

Aurora. Colorado 80014, USA 

Phone 13031696-6100 

telex: 5106013154 INDPRES DVR UQ 























_ President’s MESSAGE 
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Edward A. Parrish, Jr. 
Computer Society president 


Our professional staff 


The Computer Society has 
experienced tremendous growth over 
the past few years. Our membership 
now exceeds 90,000 and is roughly one- 
third the size of the IEEE itself. As 
such, the society can no longer be run 
out of the president’s hip pocket. 

The Board of Governors has recog¬ 
nized this growth and the necessity of 
adding staff to ensure that our member¬ 
ship services do not suffer because of it. 
At present, our staff consists of 76 dedi¬ 
cated individuals, located in Washing¬ 
ton, DC, Los Alamitos, California, 
Brussels, and Tokyo. 

Every facet of Computer Society 
activity now depends heavily upon both 
staff and volunteer involvement. It 
ranges from the highly visible activities, 
such as our publications, to the internal 
finance and information-processing 
operations. This dependence was 
increased by the recent constitutional 
changes limiting the president’s term to 
one year. 

This month’s column profiles those 
staff members who most directly inter¬ 
face with the volunteers. They are 
highly professional and deserve recogni¬ 
tion for their efforts to make the Com¬ 
puter Society the best professional 
organization in the world. 

Michael Elliott, executive director. 

Elliott joined the Computer Society as 
its first executive director in June 1982. 
A native of Indiana, he previously 
served at Purdue University as assistant 
to the president and as assistant provost 
of the university, as executive director 
of the National Commission of United 
Methodist Higher Education, as deputy 
commissioner of higher education of 
the state of Missouri, and as executive 
director of higher education of the state 
of Arkansas. The latter position 
included membership in the governor’s 
cabinet. Elliott earned bachelor’s, 
master’s, and doctoral degrees from 


Indiana University in Bloomington, 
Indiana. As executive director of the 
Computer Society, he heads a staff of 
76 persons in the society’s four offices 
in Washington, DC, Los Alamitos, 
California, Brussels, and Tokyo, and he 
oversees society operations with a total 
annual budget of $16 million. During 
Elliott’s six years as executive director, 
the society has experienced substantial 
growth in virtually all program areas. 

He has twice received the society’s 
Meritorious Service Award and is a 
biographeein Who’s Who in America. 
He lives with his wife, Loretta, in 
Washington, DC, and has a son, 
Christopher, age 16. 

True Seaborn, editor and publisher. 

Seaborn joined the society in 1973 as 
editor and publisher of Computer and 
manager of the Computer Society’s 
office in California. Since that time the 
society has launched five additional 
magazines — Computer Graphics & 
Applications, Micro, Design & Test, 
Software, and Expert — and the West 
Coast staff has expanded to 40. As edi¬ 
tor and publisher, Seaborn has overall 
operational responsibility for magazine 
quality, schedule, and budget perfor¬ 
mance ($5 million in FY88). Before 
joining the Computer Society, he held 
several writing and editing positions in 
the computer and aerospace industries, 
including TRW, Booz Allen Applied 
Research, Caltech, Computer Machin¬ 
ery Corporation, and Computer 
Sciences Corporation. He holds a BA in 
English from the University of Califor¬ 
nia at Riverside, where he graduated 
cum laude in 1958. He continued his 
studies under a Ford Foundation Fel¬ 
lowship at Claremont Graduate School 
in Claremont, California. Seaborn 
holds a number of Computer Society 
awards, including the first Harry Hay- 
man Award for Distinguished Staff 
Achievement (1987), the Outstanding 
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Contribution Award (1985), the IEEE 
Centennial Medal Award (1984), the 
Computer Society Special Award (1979; 
at that time, the society’s highest service 
award), and several Certificates of 
Appreciation. Seaborn has five children 
— Andrew (33), Phillip (29), Kerry (26), 
Julia (17), and Jason (13). He resides 
with his wife, Gaye, and their two 
youngest children in Los Alamitos. 

Chip G. Stockton, director of the 
Computer Society Press. Stockton 
joined the Computer Society in 1980 to 
head the newly formed Computer Soci¬ 
ety Press, based in the Washington 
office of the society. Since that time, 

CS Press has grown in annual sales to 
over $3 million and in staff to 19. As 
director, Stockton has overall responsi¬ 
bility for all phases of activity of the 
operation — budgeting, staffing, mar¬ 
keting, sales, and inventory control. 
Before joining the Computer Society, 
he was manager of operations for the 
Society for Computer Simulation, 
based in San Diego. His earlier back¬ 
ground included service as an art direc¬ 
tor and technical illustrator. He holds a 
BS in business management from 
California State University, Humboldt, 
and has done graduate work at San 
Diego State University. He was 
awarded the Outstanding Contribution 
Award — the first staff member to 
receive such an award — for his work in 
developing the Computer Society Press. 
Stockton is a member of the American 
Society of Association Executives, 
Council of Engineering and Scientific 
Society Executives, IEEE Professional 
Communications Society, Society of 
Scholarly Publishing, and Society for 
Technical Communication, in whose 
annual contest on quality in technical 
documentation he currently serves as a 
judge. He resides in Silver Spring, 
Maryland, with his wife, Deborah, and 
their two sons, Jeffrey and Erik. 

Anne Marie Kelly, director of confer¬ 
ences and tutorials. Kelly joined the 
Computer Society in February of this 
year, having previously served as con¬ 
ference manager and director of confer¬ 
ence logistics for the Direct Marketing 
Association and as assistant to the 
director for the National Conference of 
State Historic Preservation Officers. In 
her present capacity she oversees staff 
support and financial operations of 
conferences sponsored by the Computer 
Society. Her staff of four provides con¬ 
ference budget, promotion, registra¬ 
tion, and logistic support at the request 
of volunteer conference organizers. In 
addition, she assists the vice president 
for conferences and tutorials in review¬ 


ing conference proposals and budgets 
totaling over $4 million annually, and 
she reviews all contracts relating to con¬ 
ferences. Kelly holds an AB in Ameri¬ 
can studies from Georgetown 
University. A native of Philadelphia, 
she lives in Arlington, Virginia. 


Mary Ellen Curto, director of finance 
and administration. Curto joined the 
Computer Society as its first director of 
finance in July 1985. The scope of her 
responsibility was increased in 1987 to 
include administration as well as 
finance, and today she heads a staff of 
19 accounting, data processing, and 
administrative services people located in 
the Washington and Los Alamitos 
offices of the society. Before coming to 
the Computer Society, she worked in 
the Finance Department of Marriott’s 
International Headquarters, was direc¬ 
tor of business affairs for the Satellite 
Distribution Division of National Pub¬ 
lic Radio, and served as comptroller for 
the American Association of University 
Professors. A native Washingtonian, 
she received a BS in business finance 
from the University of Maryland and is 
enrolled in the American Society of 
Association Executives Certification 
Program. Curto lives with her husband, 
Michael, and daughter, Paulina, in 
Bethesda, Maryland. 


Nell A. Nachtergal, European Opera¬ 
tions manager. Nachtergal joined the 
Computer Society in October 1985 to 
manage its first European office and 
support the society’s growing activities 
in Europe. Working from an office in 
Brussels and backed up by a staff of 
two, she is responsible for CS Press 
order processing, implementing mem¬ 
bership and subscription promotional 
efforts, providing information for 
members and nonmembers alike, and 
serving as general liaison and coordina¬ 
tion point for society efforts in Region 
8. She came to the society with an 
extensive background in the European 
operations of several major US compa¬ 
nies, including ITT Europe (Treasury 
and Finance Departments), Intel 
Europe (Sales and Marketing Depart¬ 
ments), and Apple Computer, where 
she helped launch Apple offices in Paris 
and elsewhere in Europe. A Belgian 
national, she is fluent in French, Eng¬ 
lish, and Dutch and has a working 
knowledge of Spanish and German. She 
holds a diploma in business administra¬ 
tion and a BA in English from Cam¬ 
bridge University, and has been 
awarded the society’s Meritorious Ser¬ 
vice Award. She lives in Brussels with 
her son, Julian, 16. 


Violet S. Doan, assistant to the 
executive director. Doan joined the 
Computer Society in early 1987 to fill 
the newly created position of assistant 
to the executive director, aimed at 
streamlining the work flow in the execu¬ 
tive director’s office. Her other respon¬ 
sibilities include participation in 
planning efforts in concert with volun¬ 
teers, management, and staff. She 
recently relocated to the Washington 
area following her husband’s transfer 
there from Dallas, where she had been 
executive assistant to the president and 
CEO of the DHM Corp. of Dallas, a 
firm engaged primarily in buying and 
selling computer, oil services, and phar¬ 
maceutical companies. Earlier she was 
assistant to the president of the Seeley 
Company, a major Southern California 
real estate corporation. Doan holds a 
BS in business education from Bob 
Jones University, Greenville, South 
Carolina, and has completed course- 
work toward her MBA at the University 
of Southern California. She was 
recently awarded the society’s Certifi¬ 
cate of Appreciation for her support to 
the Board of Governors. Doan resides 
with her husband, John, in Rockville, 
Maryland. 


Kyoko Mikami, Asian Operations 
manager. Mikami is the newest addition 
to the Computer Society’s management 
team, joining the society this May as 
manager of the society’s newest office 
in Tokyo, Japan. Mikami attended 
Waseda University in Tokyo (English 
literature and accounting) and also 
received training at the Tokyo Account¬ 
ing Center. She previously worked in 
the Tokyo offices of two non-Japanese 
firms, Wella Cosmetics (German) and 
Parker Pen (USA). Her first tasks for 
the society will include all the logistics 
of starting a new office: finding office 
space, obtaining necessary equipment, 
arranging for vendor services and sup¬ 
port, hiring a secretary, etc. She hopes 
to be ready to begin providing member 
services from Tokyo early in the third 
quarter of 1988. The Tokyo office will 
assist members in obtaining society 
information and services, handle mem¬ 
bership promotions, disseminate infor¬ 
mation about society programs and 
services such as conferences, periodi¬ 
cals, and books, assist in Asian confer¬ 
ence arrangements, and facilitate faster 
service to Asian members and others 
who purchase publications through the 
Computer Society Press. 


Edward A. Parrish, Jr. 
Computer Society president 


COMPUTER 




WHAT’S REALLY IMPRESSIVE 

About Our case Tools 



Beside the price is: 

NO TRAINING REQUIRED - 
5 MINUTE INSTALLATION 

Over 4000 Installations Worldwide without one day 
training or consulting services - now that’s “easy to use” 

NO EXPENSIVE HARDWARE REQUIRED 

Our modular products are designed to provide the 
maximum productivity for your MIS budget. 
Communications in a standard format 
is now possible at a realistic price. 



EXCELLENT UPDATE PROGRAM, SERVICE AND SUPPORT 

For only $50 per tool/per year, you’ll automatically receive all updates-that will keep you in tune with the evolution of CASE. 


Ever since Computer Aided Software 
Engineering products came on the market, 
interest in them has been high. And so, not 
surprisingly, has the cost of owning them. 

But now Visible Systems is offering state-of- 
the-art CASE technology at an incredibly 
affordable price. 

The Visible Analyst Workbench is the 
only modular PC based CASE product that runs 
on the IBM 3270, XT, AT, PS/2 and 
compatibles. It consists of three integrated 
tools which can be purchased all at once as a 
package, or added one at a time as the needs of 
your organization expand. 

It’s the quality, flexibility and realistic price 
of the Visible Analyst Workbench that has 
attracted so many satisfied customers: GE, 
Shearson, TRW, Met Life, Computer Sciences 
Corp., The U.S. Government, MONY, NCR, 
3M, BellSouth, Touche Ross, Canadair and 
many more. 

THE ABCs OF OUR WORKBENCH. 

TOOL A, THE VISIBLE ANALYST 

A diagramming tool that allows you to put 
virtually any organizational idea down on paper 
quickly, easily and accurately. 

With mouse-driven graphics and pop-up 
menus, it is designed to produce everything 
from sophisticated systems analysis diagrams 


for developing and documenting software 
systems to the most basic organizational charts 
used in just about any field. 

The Visible Analyst features a custom 
symbol generator, multiple line styles and text 
fonts, flexible text processing and editing, line 
rubberbanding, block move, unlimited nested 
decompositions and project treefile 
manipulation. 

If that impresses you, just wait until you see 
our graphics go from your monitor to your 
printer - with an output of 180dpi, you're going 
to be looking at real presentation quality. 
TOOL B, THE VISIBLE RULES 

A package which brings the benefits of 
structured analysis techniques to the 
diagramming power of Tool A. It supports the 
structured methodologies of Yourdon/ 
DeMarco and Gane/Sarson and balances and 
validates dataflow diagrams over any number 
of levels. 

With The Visible Rules, communication 
between project members is greatly enhanced, 
productivity improved and costly errors 
uncovered much earlier in the lifecycle of a 
project. 

TOOL C, THE VISIBLE DICTIONARY 

A fast, comprehensive, easy-to-use tool for 
database management and system 
documentation designed for use with the 


combination of Tools A and B. The Dictionary 
database serves as a central definition 
catalogue that generates detailed 
documentation, provides uniformity of 
expression among all analysts on a team, and 
simplifies future analysis and revision. 

The database is automatically populated as 
each item is drawn. Selective and wildcard 
searches can be performed. ASCII file formats 
provided for import/export. 

And like the other two tools, its operation is 
seamless, allowing you to go back and forth 
between diagrams and dictionary without even 
taking the time to reload programs. 

LAN WORKBENCH 

The Visible Analyst Workbench operates 
on Portables, Standalones and shortly on 
Novell LANS. Files can be shared across 
departments or locked as needed. The 
executable modules can be downloaded to 
individual workstations as desired to reduce 
traffic on the net and increase operating speed. 

The best news we’ve saved for last - only 
$595 per tool -- and in quantities of 50 only 
$327.25 per tool. Find out why so many 
companies have decided to grow in CASE with 
us. 

The solution is plainly VISIBLE. It’s just 
common sense. 


CALL 617-969-4100 or Telex 261102 

VISIBLE SYSTEMS CORPORATION 

49 Lexington St., Newton, MA 02165 
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Moving Information 
From One Era Into Another 



At GTE’s Computer and In¬ 
telligent Systems Laboratory, 
we’ve intensified our focus and 
created new opportunities in Soft¬ 
ware and Information Engineering 
and Artificial Intelligence. Here, 
we apply new ideas to research 
and development projects for im¬ 
proved information and telecom¬ 
munication systems. 

By expanding our scope and 
responsibility, we can better sup¬ 
port GTE’s telecommunications 
businesses. And our activities 
create challenges for individuals at 
the MS/PhD level in Computer 
Science. Join us as we continue to 
make history in telecommunica¬ 
tions technology. 


Areas of expertise: 

• SOFTWARE REUSABILITY 

• PROGRAMMING 
ENVIRONMENTS 

• SOFTWARE-DEFINED 
SERVICES FOR 
INTELLIGENT NETWORKS 

• INFORMATION RETRIEVAL 

• INTELLIGENT DATABASE 
MANAGEMENT SYSTEMS 

• APPLIED EXPERT 
SYSTEMS 

• EXECUTABLE 
SPECIFICATIONS 

• RAPID PROTOTYPING 

• ENTERPRISE ANALYSIS 
AND BUSINESS MODELING 


• DISTRIBUTED ARTIFICIAL 
INTELLIGENCE 

• LOGIC PROGRAMMING 

• MACHINE LEARNING 

• OPERATING SYSTEMS 

• CONNECTIONIST 
MODELING 

GTE Laboratories offers attrac¬ 
tive facilities located in a quiet, 
wooded setting just outside of 
Boston as well as a highly com¬ 
petitive salary and benefits pack¬ 
age. We invite you to send a 
resume to Vanessa Stem, GTE 
Laboratories, Inc., Box IEEE6, 
40 Sylvan Road, Waltham, MA 
02254. An equal opportunity 
employer, M/F/H/V. 
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The Optical 
File Cabinet: 

A Random-Access 
File System for 
Write-Once Optical Disks 

Jason Gait, Tektronix 


he Optical File Cabinet, a 
random-access file system for 
write-once optical disks, is pat¬ 
terned after a conventional office file cabi¬ 
net where all versions of a stored item are 
retained, but the current version of each 
item is the easiest to find. The OFC is large 
and can be expanded, if necessary. It uses 
the space taken up by old versions of files 
very purposefully, since old versions of 
files may be required later — for histori¬ 
cal or legal reasons — to replace current 
versions that don’t work out or to supple¬ 
ment the information content. The OFC 
retains old file copies, just as in a conven¬ 
tional office, and is equipped with a com¬ 
petent secretary for rummaging through 
files and retrieving imprecisely specified or 
not immediately available data. 

The OFC uses data structures that can 
be recorded on a write-once optical disk 
yet can be dynamically enlarged and 
altered if files are updated. Over the life of 
the write-once media — about 10 years — 
many records will be superceded, so the 
OFC conserves disk space by updating 
both on a block-by-block basis and using 
copy-back caching strategies. Although 
the write-once media is stable, the OFC has 
a procedure for recovering optical-disk 
data in case of CPU and controller 
failures. The visible part of any disk sub¬ 
system is the performance of read opera¬ 
tions. 1 Since read operations exceed write 



The OFC exploits the 
favorable aspects of 
write-once optical 
disks while preserving 
the existing 
relationship between 
the operating system 
and the file system. 


operations by ratios ranging from 2:1 to 
10:1, 2 the OFC optimizes read perfor¬ 
mance at the expense of write operations. 
To preserve compatibility with existing file 
system structures and with user expecta¬ 
tions, the OFC supports random access to 
files across familiar user interfaces. To the 
operating system, the OFC appears to be 
a conventional magnetic disk. All manage¬ 
ment of the complex media is contained 
within the OFC, making operating system 
changes unnecessary. 


Alternate approaches 
to write-once storage 

Alternate approaches to storing data on 
write-once media include an append-only 
method, 3 in which new data is added to 
the end of the data; a copy-only tech¬ 
nique, 4 in which the entire file is copied 
elsewhere on the media whenever it is 
updated; storing data on optical disk and 
auxiliary information on magnetic disk; 5 
and the use of B-trees for database appli¬ 
cations. 6,7 

The append-only approach is suitable 
for files in which new records are added to 
the end of already written records, for 
instance, log files. The copy-only method 
is appropriate for files that will rarely be 
updated. In the optical/magnetic 
approach, unorganized data is stored on 
optical media, and the data structure 
needed to make the optical data intelligi¬ 
ble is stored on magnetic media. Using this 
method, a failure in the magnetic media 
will cause the data stored on the optical 
disk to be lost also. The last approach, 
using a B-tree to organize the data on opti¬ 
cal media, uses the media inefficiently. 

The OFC method is closest to the copy- 
only approach because files are stored on 
the write-once media and can be arbitrar¬ 
ily updated, along with all organizing 
structural information, which is also 
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stored on the write-once media. However, 
the OFC is more efficient than a copy-only 
approach — in terms of disk usage and 
performance — because it updates data on 
a block-by-block basis. 

Write-once 
optical disks 

The limitations of write-once optical 
media circumscribe the way they can be 
used most productively. 810 Although read 
operations have a low residual error rate 
(typically one bit in 10 12 ), their raw error 
rate is high, and error-correction codes are 
necessary to make optical storage viable. 
Optical disk storage is organized into units 
called blocks, which are contiguous units 
of storage that are read and written 
indivisibly. When a block is written to 


disk, the corresponding error-correction 
code is also written in a conventional loca¬ 
tion. Thereafter, the error-correction code 
cannot be changed. For this reason, indi¬ 
vidual disk blocks, once written, are never 
updated, even when there is room in the 
block for more information. 

There are two consequences of this 
approach. The first is that waiting to allo¬ 
cate list structures until it is time to store 
them on the media (lazy allocation) will 
not work, forcing a preallocation strategy. 
The second is that altering data requires 
the new data to be written to new disk 
locations. 

Controllers for write-once optical disks 
treat unused, unwritten blocks differently 
from blocks that have been written. An 
unused block has no error correction code 
associated with it, so attempting to read an 
unwritten block returns an error, a feature 


Terminology 

Access skew — unbalanced file access pattern 

Checkpoint interval — time between the periodic recording of timestamps on 
write-once media 

Compressing the media — a media replacement procedure that copies only 

the active file system, and not outdated files, to new media 

Continuation list — a growable list structure for write-once media in which a 

block is written to disk and the next block is preallocated 

Copy-back — a cache discipline that updates the disk some time after the 

cache copy has been updated 

Distal — a high-latency seek that requires movement of the drive head 
Dominated block — a block of stored data that has been superceded by an 
updated version stored elsewhere on the media 

File system tree (FST) — the data structure that organizes the logical disk so 
it can be updated block-by-block with minimal overhead; the logical disk is 
formed from the leaves of the tree 

Media lifetime — the interval between the time of first writing to the optical 
media and the time the media is full and must be replaced by new media 
New media transition — the process of copying the active file system to new 
media when the old media is full, leaving the old media for backup 
Proximal — an efficient optical seek to a block near the drive head, achieved 
by purely optical means, without moving the drive head 
Proximal window — the average range of blocks that can be read by purely 
optical means without moving the drive head; typically four megabytes 
Readahead — number of proximally located blocks that the disk driver prepo¬ 
sitions in the file cache when a block is read; current practice uses one extra 
page 

Shelf life — length of time an optical disk can be stored without physical 
deterioration of the media 

Timestamp list — a continuation list of timestamps; the last timestamp 
defines the current logical disk 


that has important practical applications. 
If the write-once optical media is written 
to sequentially, then the unwritten area of 
the disk will be delimited by the first 
unwritten block. Some controllers — for 
example, the Sony WDD-2000 — do not 
protect written blocks, except for the 
error-correction code, from being over¬ 
written by software error. In this case, a 
read-before-write policy is necessary to 
protect written data from accidental cor¬ 
ruption. In this approach, new data is writ¬ 
ten only when a read test signals an 
unwritten block. 

The average seek time for optical disks 
is an order of magnitude larger than aver¬ 
age seek time for magnetic disks, but the 
seek times to blocks near the position of 
the recording head are an order of magni¬ 
tude smaller than their magnetic disk 
counterparts. 11 This is because an optical 
disk head seeks to nearby blocks by rotat¬ 
ing a small lens, a more efficient mechan¬ 
ical operation than the linear head 
assembly movements used by magnetic 
disk controllers. Optical seeks to nearby 
blocks are called proximal, and seeks to 
distant blocks, which require head move¬ 
ment, are called distal. The proximal win¬ 
dow is the average number of disk blocks 
that can be scanned by purely optical 
means (without moving the disk head). 
Seeks within the proximal window are 
referred to as local seeks. For example, the 
proximal window for the Fujitsu M2505A 
optical disk controller is four megabytes, 
or 4000 pages. 

With present technology, individual 
disk media sizes range up to eight gigabytes 
(Kodak). Optical disk autochangers, 
called jukeboxes, 12 can be configured 
with up to one terabyte (Kodak), and opti¬ 
cal tape jukeboxes are available with up to 
one terabyte (DOCdata). 

File system tree 

The operating system treats the logical 
disk as a strict linear ordering of data 
blocks. There is an indirect relationship 
between the logical data and the physical 
storage when a file is physically placed on 
write-once media. The OFC preserves the 
expected logical disk interface to the oper¬ 
ating system by recreating a strict linear 
order in the form of the leaves of a tree. 

Logical vs. physical representation. The 

OFC accesses the logical disk through a 
tree-shaped arrangement of pointers called 
the file system tree. Figure 1 shows the 
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FST, whose leaves contain the logical disk 
blocks seen by the operating system. The 
root block of the FST is always a block of 
pointers that point to a second level of disk 
blocks. The second-level blocks contain 
additional levels of pointers, logical disk 
blocks, or empty blocks. The 32-bit page 
pointers can address up to four billion log¬ 
ical disk blocks, or up to four terabytes of 
data stored on the optical media. This 
technique supports all existing media, 
while still allowing the OFC to compute 
the physical disk location of any block in 
the logical disk efficiently. These efficien¬ 
cies are realized by caching the pointer 
nodes, and by computing pointer offsets 
using mask and shift operations. Either the 
FST can be sized so that the logical disk 
fills nearly the entire optical disk (with little 
space allowed for updates), or the logical 
disk can be sized so that it occupies only 
part of the optical disk at any one time. To 
provide space for updates, the logical disk 
might occupy about five percent to 10 per¬ 
cent of the physical disk at any one time. 
The remaining disk space is either empty 
or filled with old versions of files. 

Small file system. A small 65-megabyte 
logical disk using one-kilobyte blocks of 
physical storage is suitable for an active file 
system on a one-gigabyte optical disk. It 
uses a three-level FST, with the root block 
of the tree identifying 256 secondary 
blocks of pointers, each of which points to 
256 other blocks. The overhead of interior 
nodes is about 0.4 percent of the physical 
FST. 

Medium file system. A medium-scale 
16-gigabyte logical disk, suitable for an 
active file system on a 365-gigabyte juke¬ 
box, uses a four-level FST. The overhead 
of interior nodes is still about 0.4 percent 
of the physical FST. 

Large filesystem. One practical way to 
extend the OFC into the terabyte range is 
to partition the available media into 
several small- or medium-scale logical 
disks. For example, a one-terabyte optical- 
tape jukebox conveniently supports three 
logically disjoint medium-scale logical 
disks. 

The logical to physical translation. The 

operating system requests logical blocks 
from the OFC. In a magnetic-disk file sys¬ 
tem, no further computation would be 
required, because the logical and physical 
block locations coincide. In the OFC, an 
additional computation is needed to locate 
the requested logical block in the FST. 
How the OFC converts the requested log¬ 


nodes 



Figure 1. The file system tree can support a 65-kilobyte logical disk. Larger logical 
disks can be supported by adding layers of interior nodes to the tree, up to the stor¬ 
age capacity of the media. Managing interior nodes is inexpensive because the 
interior nodes are cached in memory. 


ical block number to a physical block 
depends on the size of the system. 

Smallfilesystem. Given a one-kilobyte 
logical block n, the two required offsets 
into the physical FST (shown in Figure 2) 
are 

offset in root node = n div 256 
offset in first level interior node = 
n mod 256 

where the div operator produces the 
integer part of the quotient of n and 256, 
and the mod operator produces the integer 
remainder. 

Medium file system. Given a logical 
block n , three offsets are required: 
offset in root node = n div (256*256) 
offset in first level interior node = 

(n div 256) mod 256 


offset in second level interior node = 
n mod 256 

Large file system. The offsets into the 
FST required to partition a large physical 
disk into logical disks are generalized from 
computations for the medium-scale file 
system. 

Growable 
data structure 

Data structures written to a write-once 
medium cannot subsequently be altered in 
place, so they must change by growing. To 
do this, the OFC uses a continuation list 
that allows the file system to evolve 
dynamically. There is nothing rigid about 
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the algorithms used by the OFC or static 
about the data structures they manipulate. 


Leaf 

nodes 



Root offset = n div 256 
Page offset = n mod 256 


Figure 2. Computing the offsets for a small logical disk. The derivation of the 
physical location of a logical page is inexpensive because computations are carried 
out using mask and shift operations. 



Preallocated 

for 

continuation 


Figure 3. The continuation list is a growable data structure for write-once media. 
Whenever a block is written to disk, the next block is preallocated. 


Continuation list. A continuation list, 
shown in Figure 3, is a sequence of disk 
blocks whose entries consist of either data 
or pointers to other disk blocks. The list is 
linked by the last pointer entry in each 
block of the list. Whenever a block belong¬ 
ing to a continuation list is written to the 
disk, a continuation block is preallocated, 
or designated for future use, and a pointer 
to the preallocated block is included in the 
block being written. Lazy allocation of the 
continuation block does not work with 
write-once media because the last block in 
the written list cannot be updated with a 
pointer to the next block. 


Timestamp list. The OFC records 
timestamp blocks, each defining a snap¬ 
shot of the file system, in a continuation 
list (see Figure 4). A timestamp contains 
pointers to the root block of the FST and 
to a block of accounting information, as 
well as a pointer to the continuation block. 
The OFC periodically performs a check¬ 
point procedure that flushes all caches to 
disk and writes the timestamp. The check¬ 
points define the granularity with which 
snapshotted versions of files can be recov¬ 
ered. The last checkpoint defines the cur¬ 
rent logical disk. 

At boot-up time, the OFC traces 
through the timestamp pointer chain to the 
last timestamp and locates the currently 
active version of the logical disk. The last 
timestamp is easily identified because the 
continuation block has not been written. 

Updating the disk. When a block of 
data in the logical disk is replaced, several 
interior nodes of the FST must also be 
replaced, and a new timestamp must be 
generated (see Figure 5). When interior 
nodes are read, they are stored in a copy- 
back cache in memory to improve the per¬ 
formance of the read operation, to limit 
the frequency of writing interior nodes to 
the disk, and to keep the interior node 
information needed to update the disk 
readily available. 

Bootstrapping the OFC. A bootstrap 
for the OFC must be able to locate the 
timestamp list on the disk, trace down the 
pointer chain to the last timestamp, 
manipulate the FST to access the logical 
disk, and then load the operating system 
(including the OFC) into memory from the 
disk. 
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tree 


Accounting 

information 


Figure 4. The timestamp list is used to 
record a checkpoint of the logical disk. 
The timestamps form a continuation 
list, and the last written continuation 
block in the list is the current 
timestamp. In the event of a CPU or 
controller failure, the logical disk is 
recovered in a consistent state by fol¬ 
lowing the pointer chain in the continu¬ 
ation list to the last timestamp. 
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Figure 6. The relationship between the Optical File Cabinet and the operating 
system. 


Large memory 
requirement 

The OFC can function correctly with 
conventional memory resources, but large 
memories in the megabyte range are 
needed for high-performance operation. 
There are four reasons for this: (1) to allow 
a longer interval between cache flushes for 
accumulating updates before disk writes, 
(2) to cache interior nodes of the FST in 
memory, (3) to allow a large readahead 
cache, and (4) to allow locking of file sys¬ 
tem procedures in memory. 

Accumulating updates. An update to a 
file will often be superceded by later 
updates while the file is still open. There¬ 
fore, a more efficient use of the disk would 
be to accumulate updates and write them 
to disk at checkpoint time, thus avoiding 
wasted writes. The writing of accumulated 
updates to contiguous storage is consistent 
with the observed access locality patterns 
for files, referred to as access skew, where 
a relatively small number of files account 
for a relatively high proportion of 
accesses. 13 


Advantages of write-once optical disks 


Write-once optical disks exhibit several advantages over 
magnetic disks for file storage: they are not susceptible to 
media failure; data is never rewritten; the high performance 
of proximal seeks may exceed that of magnetic disks; an 
optimal cache copy-back policy is practical; and they are 
easy to handle. 

Stable storage. Optical disks are resilient to media fail¬ 
ure. Therefore, they are an appropriate and convenient 
choice for file systems. The media is covered by a hard 
plastic coating, making it impossible for the drive-head 
mechanism to damage it. Optical disks then provide safe 
and consistent storage, without requiring special 
precautions. 

Version histories. Since no data is ever overwritten, the 
history of the file system is preserved on the media. Aux¬ 
iliary data structures may be required to retrieve arbitrary 
snapshots of all or part of the file system, but in principle 
any given version of a file is available for future reference 
with little disk overhead. 

Optimizing read performance. The read performance of 
an optical file system is not necessarily worse than that of 
a magnetic-disk system. Optical disks exhibit an advan¬ 


tage for proximal seeks. A mature optical file system is 
spread out over the disk, but the active part tends to be 
localized in a window of nearly contiguous blocks. Within 
this window, seek performance is potentially superior to 
the seek performance of a magnetic disk. Because the 
transfer times for magnetic and optical technologies are 
approximately the same, write-once optical disks can be 
used in place of magnetic disks in any data-logging appli¬ 
cations typically reserved for magnetic media. 

Optimizing cache performance. The file cache is an in¬ 
memory collection of disk blocks belonging to files being 
accessed by the process set. Writes by applications are to 
the file cache, and many of these blocks may be overwrit¬ 
ten or deleted before the file is closed. The optimal policy 
is to delay writes from file cache to disk until a block is 
about to be eliminated from the file cache. This strategy is 
unsafe for magnetic disks because some blocks may never 
be eliminated from the cache, but it is favorable for optical 
disks, where periodic timestamps are taken, because it 
conserves disk space by accumulating updates. 

Ease of handling. Optical media are removable, easily 
transported, and hard to damage. 
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Caching interior nodes of the FST. The 

OFC caches FST interior node informa¬ 
tion needed to construct the continuous 
virtual block array expected by the oper¬ 
ating system. The efficiency of manipulat¬ 
ing the file system tree depends on the hit 
ratio to the interior node cache. 

Readahead buffering. A current prac¬ 
tice in data processing involves reading one 
or more related, or prepositioned, pages 
and storing them in a nearby file cache, 
anytime a page is read from disk. The term 
readahead is used to denote the number of 
prepositioned pages. Four to 16 one- 
kilobyte cache blocks are appropriate for 
file readahead, so the readahead buffer 
may contain all or most of the data for the 
average one- to 11-kilobyte file. The 
apparent result of readahead is to increase 
the ratio of proximal to distal reads, 
thereby enhancing the performance of the 
file system. 

Locking file system procedures in mem¬ 
ory. File system procedures such as copy, 
remove, and so on, involve distal seeks 
when they are retrieved from optical media 
at the same time as the files they manipu¬ 
late. The reason for this is that these proce¬ 
dures are rarely replaced, so they tend to 
reside at the beginning of the disk. At the 
same time, the files they access are succes¬ 
sively updated and tend to be found at 
increasingly more-distal locations. These 
distal operations can be avoided by lock¬ 
ing the most commonly used file system 
procedures in memory. This strategy can 
buffer about one-third of all disk reads in 
memory, taking up about one-fourth of a 
megabyte. 2 

Relationship between 
the OFC and the 
operating system 


Virtual 

disk 



Virtual 

linear 

array 


Figure 7. The relationship between the logical disk and write-once physical storage. 


Figure 6 shows the relationship between 
the OFC and the operating system. Oper¬ 
ating systems and many system utilities — 
in particular, utilities that maintain the file 
system — depend on conventional inter¬ 
faces between the operating system and the 
file system. These established interfaces 
must be respected. Thus, the interface 
between the OFC and the host operating 
system is predefined. 

To ensure reasonable performance, for 
instance, to avoid physical copy of disk 
blocks in memory, any block that can be 
accessed by the operating system must be 
stored on the write-once disk in the precise 


form called for. The OFC provides a dis¬ 
tinct interface between the operating sys¬ 
tem and the OFC, so neither the OFC nor 
the host operating system needs to know 
anything about the internals of the other. 
There is no direct interaction between the 
two; the operating system manages the 
logical disk in terms of logical blocks with¬ 


out needing to know how physical blocks 
are stored on the disk, while the OFC treats 
the logical block numbers as offsets into 
the tree of physical blocks stored on the 
media (see Figure 7). This process allows 
logical blocks to change their physical 
locations on disk when their contents 
change. As a result, the OFC is conceptu- 
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Figure 8. Recovery of write-once optical media after a system failure. 


ally portable to many operating systems, 
in particular, to any version of Unix; the 
only operating system changes required 
are installing driver entry points and 
recompiling. 

The OFC is self-contained and does not 
require magnetic media to store auxiliary 
data structures. All auxiliary information 
is stored with the data on optical media. 
The OFC updates data — on a block-by¬ 


block basis, rather than file-by-file — at 
the smallest write granularity provided by 
the optical technology. The operating sys¬ 
tem, rather than the OFC, manages the file 
system readahead and copy-back page 
cache. 

Caching strategies. The relatively slow 
average seek-performance of current opti¬ 
cal controllers has encouraged a variety of 


caching strategies to minimize distal seeks. 
The operating system and the OFC use 
copy-back cache disciplines. A copy-back 
discipline updates cached data, but does 
not update the disk copy until some later 
time. The OFC periodically flushes copy- 
back caches. The operating system oper¬ 
ates a copy-back buffer cache, while the 
OFC uses a cache of auxiliary informa¬ 
tion. This information is used by the OFC 
to organize storage on the optical media. 

These caches are flushed during check¬ 
points in intervals of several minutes. The 
checkpoint interval is the time between the 
periodic recording of timestamps on the 
optical media. Extremely short checkpoint 
intervals, say about every 30 seconds, elim¬ 
inate many of the advantages of the 
caches. Extremely long checkpoint inter¬ 
vals on the other hand, say about once 
every 30 minutes, risk losing large amounts 
of data if a failure occurs between disk 
updates. A compromise checkpoint inter¬ 
val of about five minutes will balance 
cache performance against risk. 


Reliability 

When the system fails between 
timestamps, any data in memory and any 
data written to disk after the last 
timestamp is lost. The amount of data that 
can be lost is controlled by adjusting the 
timestamp frequency. Users and specific 
applications can also force asynchronous 
timestamps. The consistency of the logical 
disk can be guaranteed by choosing an 
appropriate discipline for page writes. The 
timestamp methodology ensures that the 
data structures on the optical media that 
define the relationship between the logical 
disk and the physical disk are always main¬ 
tained in a consistent state. The logical disk 
is always consistent because the FST is 
updated before the new timestamp is 
created. The OFC completes a checkpoint 
by writing pages to the disk in the follow¬ 
ing order: (1) logical pages, (2) interior 
nodes, (3) root node, and (4) timestamp. 
In the event of failure, the logical disk is 
recovered intact up to the last checkpoint, 
so it is always in a consistent state. 

After a hardware failure, the logical disk 
is recovered by following the pointer chain 
in the timestamp list to its last element (see 
Figure 8). If a CPU or controller failure 
occurs between checkpoints, the last ele¬ 
ment in the chain will be an unwritten 
block. The next-to-last element will be the 
current timestamp. If a CPU or controller 
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failure occurs during checkpointing, the 
last element in the chain may be unread¬ 
able. In this case, the next-to-last element 
is the current timestamp. The next check¬ 
point uses the first available and readable 
continuation block that was preallocated 
in the current timestamp. The first free 
disk block is easy to identify because disk 
blocks are allocated by the OFC in strict 
sequence — from the head of the media to 
the tail. 

Secretary and 
long-term storage 

The secretary, the user-level software 
interface to the OFC, performs four tasks: 
(1) archiving, (2) version retrieval, (3) new 
media transition, and (4) performance 
monitoring. 

Archiving. The OFC integrates archiv¬ 
ing on the same optical media as the active 
file system. To archive a file, the owner 
passes the file name to the secretary, which 
archives the file by disconnecting it from 
the active file system. The archived file 
remains on the disk, and is accessible by 
the last timestamp made before it was 
archived, but does not consume any of the 
space allocated to the active file system by 
succeeding timestamps. The secretary 
maintains a directory of files that have 
been archived for each user. To retrieve an 
archived file, the secretary reintroduces the 
existing data blocks back into the active 
file system. This method efficiently moves 
archived files in and out of the active file 
system without adversely affecting the 
active file system’s size, for as long as the 
medium is active. 

Of course, after media replacement, 
retrieval of an archived file requires 
reloading the old archive disk. The secre¬ 
tary helps by identifying the required disk. 
The secretary can also be programmed to 
automatically archive user-level files that 
have not been accessed for a specified 
period of time. This archiving does not 
consume any extra disk space and makes 
more room available in the active file sys¬ 
tem, thus making the transition to new 
media less expensive. The secretary is also 
capable of retrieving accidently removed 
files by inspecting the timestamp list and 
sorting through the directories. 

Version retrieval. A block of disk stor¬ 
age that has been replaced by an updated 
version written elsewhere is referred to as 
dominated. Dominated blocks in the OFC 


are not visible to the active file system but 
may still be accessed for version retrieval. 
The OFC maintains the latest version of 
each file in the active file system and can 
access all timestamped versions of the file 
on the same disk. The secretary retrieves 
the various versions by stepping through 
the timestamp list and inspecting snap¬ 
shots of the FST at the granularity of 
timestamps. The OFC does not guarantee 
that all versions of a file can be retrieved. 
Events that change the file, or change the 
file’s directory entry, may produce differ¬ 
ent versions of a file between timestamps. 
Some of these versions may be superceded 
in the cache and not written to disk, and 
there may be several inaccessible fragmen¬ 
tary versions of files stored on the disk 
between timestamps. 

A user can force a particular version to 
be timestamped and recorded by the secre¬ 
tary in a version directory. A timestamped 


file can be retrieved by name and 
timestamp. The secretary can produce a 
summary of a range of timestamped ver¬ 
sions, or even the entire timestamped ver¬ 
sion tree, allowing a user to retrieve 
versions with incomplete retrieval infor¬ 
mation. The secretary supports such sum¬ 
maries, even when there is no current 
version for the file. 

New medium transition. Write-once 
optical media can be replaced periodically 
by compressing the old media in a process 
that transfers the newest versions of files 
to the new disk and preserves the archived 
versions in the old media. This process is 
called media transition. The frequency of 
media transition depends on the storage 
capacity of the media and on the rate at 
which the disk is written. The secretary 
compresses the file system to a newly 
installed disk when the old media becomes 


Rate of media replacement 


The table below displays a calcula¬ 
tion of media lifetime for file storage 
on write-once optical disks. The cal¬ 
culation is parameterized by disk 
size in bytes and number of pages 
per second written to disk, assuming 
a constant work load per eight-hour 
day, five-day week, and 48-week work 
year. For a physical write rate to disk 
of one page per second, economical 
one-gigabyte optical-disk systems 
can last up to seven weeks before 
media replacement is required. 


Moderate-cost eight-gigabyte sys¬ 
tems are readily available and can 
extend media life to more than a year. 
More costly jukebox systems extend 
media lifetime to the lifetime of the 
computing system. The rate of physi¬ 
cally writing pages to disk is con¬ 
trolled by increasing the size of the 
memory system, but even higher than 
normal physical writing rates are 
possible if the capacity of the disk 
subsystem is increased. This can be 
done with presently available 
hardware. 


Media size 

Pages written to disk per second 
12 4 5 

.5 gigabyte 

3 weeks 

2 weeks 

36 hours 

29 hours 

1 gigabyte 

7 weeks 

4 weeks 

2 weeks 

10 days 

8 gigabytes 

1 year 

29 weeks 

15 weeks 

12 weeks 

26 gigabytes 

4 years 

2 years 

1 year 

10 months 

365 gigabytes 

55 years 

28 years 

14 years 

11 years 

1 terabyte 

155 years 

78 years 

39 years 

31 years 


Active media lifetime, up to the transition to new media, of write-once optical 
disks used for file storage, tabulated against disk size in bytes and number of 
pages physically written on the disk per second. The calculations assume 
constant operation during eight-hour days, five-day weeks, and 48-week work 
years. Each size entry represents commercially available write-once optical 
equipment. 
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Figure 9. The media lifetime (denoting the active use of a disk and terminated by a 
media transition) of write-once optical disks used for file storage. The simulated 
media lifetime is plotted against checkpoint interval and parameterized by file 
cache size. 


full. Only the active file system appears on 
the new disk, including the files used by the 
secretary. The old disk contains archived 
files and old versions of current files and 
is kept for long-term storage. The OFC 
keeps track of the space left on the media, 
and it forces media transition after a 
timestamp has been taken and there is not 
enough room on the media to take another 
timestamp. 

Performance monitoring. Each time the 
logical disk is checkpointed, an account¬ 
ing block of performance data that is 
reachable from the timestamp is written to 
disk for future analysis. The OFC records 
the following values whenever a timestamp 
is written to disk: 

(1) average rate of disk usage in blocks 
per day since the last timestamp, which 
indicates the cumulative rate of media con¬ 
sumption; 

(2) amount of space remaining on the 
disk in blocks, which indicates the immi¬ 


nence of media transition to the OFC; 

(3) time in days since the present media 
was loaded, which indicates cumulative 
media lifetime; 

(4) estimated remaining active media 
life in days, which indicates the imminence 
of media transition to the user; 

(5) total number of timestamps on this 
media, which indicates the overhead of 
storing the timestamps; 

(6) ratio of proximal to distal seeks since 
the last timestamp, which indicates the 
efficiency of strategies to encourage prox¬ 
imal seeks; 

(7) hit rate to cache of interior nodes 
since the last timestamp, which indicates 
the retrieval overhead for the FST; and 

(8) cumulative relative fraction of 
interior nodes of FST written to disk since 
the last timestamp, which indicates the 
storage overhead for the FST. 

The secretary accesses these accounting 
blocks to monitor the performance of the 
OFC. It also prepares summary reports for 


the system administrator on request or as 
a result of new media transition. The sys¬ 
tem administrator may then use the 
accounting summary as a basis for adjust¬ 
ing control parameters that affect the per¬ 
formance of the OFC, such as the 
checkpoint interval. 


Simulating the OFC 

The objective of simulating the OFC 
was to demonstrate the feasibility of 
random-access file storage for write-once 
optical media. The simulator models a 
minimal set of operating system struc¬ 
tures, rather than a detailed reconstruc¬ 
tion. The simulation verified that 

(1) the algorithms proposed for the 
OFC are complete and correct; 

(2) the cache of interior nodes of the 
FST can have a sufficiently high hit rate to 
ensure that the interior node management 
does not affect response; 

(3) the storage overhead of timestamps 
and interior nodes is negligible compared 
to file storage; and 

(4) the storage capacity of optical media 
is sufficient for practical use. 

The simulator incorporated a model of 
a write-once optical disk, a cache for data 
pages, and a cache for the interior nodes 
of the FST. Observed average rates of 
reading from existing files, writing to files, 
creating new files, and deleting file pages 
were used to drive the simulation. 14 The 
simulation fixed the value of readahead at 
one, conforming to current practice. The 
parameters of the simulation were the size 
of the file cache, the size of the cache of 
interior nodes, and the checkpoint 
interval. 

The simulation did not treat access 
skew. In the implemented version of the 
OFC, access skew improves proximal seek 
behavior and performance of both the file 
cache and the cache of FST interior nodes. 
The simulation did not treat values of 
readahead greater than one. In the imple¬ 
mented version of the OFC, larger read- 
ahead values could preposition more pages 
in the file cache, thereby improving its effi¬ 
ciency and reducing distal seek behavior 
caused by intervening access to other files. 
Thus, the simulation deliberately reflected 
a pessimistic, worst-case view of optical 
file system performance. Even with these 
worst-case assumptions, the simulation 
indicated that optical file systems are a 
practical alternative to magnetic file 
systems. 
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Figure 10. Effectiveness of the cache of internal nodes of the file system tree. Simu¬ 
lated hit ratio to the cache of internal nodes is plotted against cache size. The curve 
is very pessimistic because the simulation assumes that there is no skew in file sys- 


Media lifetime. The shelf life of an opti- [ 
cal disk is the length of time it can be stored l 

without physical deterioration of the 
media, typically between 10 and 30 years. 

The media lifetime of a write-once optical 
disk is the time between the first writing to 
the disk and its last timestamp, at which 
time it is full and must be replaced by a new 
disk, assuming that it has been written to 
at a reasonable rate. The media lifetime 
delimits the expected active life of a disk. 

Pages are physically written to disk in 
three circumstances: (1) during periodic 
cache flushes, (2) as part of cache replace¬ 
ment, and (3) while maintaining the 
timestamp list and the interior nodes of the 
FST. In the simulator, cache flushes occur 
in a regular sequence determined by the 
checkpoint interval. The bulk of all pages 
physically written to disk are processed 
during cache flushing. Cache replacement 
can cause a relatively small number of 
pages to be written to disk to make room 
in the file cache for new page activity. The 
rate of cache replacement is controlled by 
the size of the file cache. 

Figure 9 plots the simulated media life¬ 
time to transition against the checkpoint 
interval, parameterized by file cache 
size. When the file cache is small, the simu¬ 
lated media lifetime is independent of 
the checkpoint interval, so a relatively 
small checkpoint interval can be used with¬ 
out sacrificing performance. For larger file 
caches, the simulated media lifetime 
increases as the checkpoint interval 
increases, so optimal performance is 
obtained by increasing the checkpoint 
interval. Media lifetime always increases 
when the file cache increases, so the file 
cache size is the dominant factor in effi¬ 
cient use of optical media. For optimum 
overall performance, the OFC would use 
a large memory, a large file cache, and a 
long checkpoint interval. 

Cache of interior nodes. Figure 10 
shows the simulated hit ratio to the cache 
of internal nodes of the FST plotted 
against the cache size. This graph 
represents a pessimistic view, since access 
skew was not simulated. In practice, the 
actual hit ratio is high for even relatively 
small caches. For example, the effect of 
access skew on the Unix index-node cache 
leads to a 90-percent hit rate for a cache of 
only 100 index nodes. In any case, if the 
file cache size is in the megabyte range, 
then an internal node cache in the kilobyte 
range is plausible. 

Proximal seeks. Figure 11 shows the 


relationship between proximal and distal 
read activity. It plots the percentage of all 
simulated proximal read activity against 
the size of the proximal window 
parameterized by file cache size. The per¬ 
centage increases as the proximal window 
is increased and as the file-cache size is 
increased. Proximal activity increases as 
the file-cache size increases because there 
are fewer disk accesses. Therefore, read- 
ahead becomes the predominant factor in 
measuring proximality. The simulator 
treats only a readahead value of one; larger 
values of readahead would probably 
increase the ratio of proximal over distal 
file accesses, provided the file cache was 
large enough to accommodate the larger 
numbers of prepositioned pages. The 
proximal window depends on the hard¬ 
ware; it is not under the control of the 
OFC. The value of the proximal window 
may help determine the choice of hard¬ 
ware, but optimal performance is in 
general attained by increasing the file 
cache size. 


Implementation 
of the OFC 

The OFC was implemented on a Tektro¬ 
nix 4404 engineering workstation running 
Unix 4.2 BSD. Two Sony WDD-2000 
write-once optical drives with eight-inch 
one-gigabyte media, a one-kilobyte block 
size, and an average seek time of about 500 
milliseconds were used. With this hard¬ 
ware, reliably writing a block to disk takes 
twice as long as reading a block. The OFC 
was installed in Unix as a driver, with no 
change to Unix other than adding new 
driver entry points. No code is required in 
the OFC to accommodate Unix. 

No magnetic media was used in the sys¬ 
tem. Unix treats the OFC as though it were 
a magnetic disk, and the OFC is self- 
contained. The first disk was used for the 
Unix root file system, and the second was 
used for paging and temporary files. When 
the file system disk becomes full, the sec¬ 
ond drive is used for new media transition, 
and the full paging disks are discarded. 
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Figure 11. Relationship between proximal and distal read activity. The simulated 
proximal read activity is plotted against the size of the proximal window and 
parameterized by file cache size. 
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The size of the file cache was four mega¬ 
bytes. Since a 20-kilobyte interior-node 
cache provided a 99-percent hit rate for 
both disks, the interior nodes do not 
impact file system performance. 

T he difference between the 
99-percent hit rate and the more 
pessimistic result predicted by the 
simulation indicates that skew in file access 
patterns is an important factor for the 
OFC. The OFC provides the necessary 
software to use jukeboxes as networked 
departmental file servers, or archivers, and 
as mainframe backup units. The software 
is capable of integrating a peripheral write- 
once optical disk into an existing Unix 
magnetic file system for backup and data 
logging applications — in particular for 
storing sequences of frame buffers — with 
the same performance as magnetic disks. 
Because it has no direct connection to the 
operating system, the OFC can support a 


stand-alone write-once optical disk, mean¬ 
ing a dedicated peripheral with no operat¬ 
ing system, as an instrument peripheral for 
waveform storage. 

With the advent of fast write-once opti¬ 
cal disks — such as the one announced by 
Pioneer Communications, with an average 
seek time of 60 milliseconds — the OFC 
may become a practical optical-only file 
system for engineering workstations. □ 
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Stepwise Refinement and 
Verification in Box-Structured 
Systems 

Harlan D. Mills 
University of Florida 


S ystem design begins in problem 
domains, usually with considera¬ 
ble informality, and ends in com¬ 
puter domains in completely formal 
languages for programmers and users. 
Ideally, the system specification should be 
defined formally first, and the system 
designed accordingly. However, there are 
few systems of any size where this is prac¬ 
tical. Even if a designer could do it, the 
sponsors and users would be hard pressed 
to understand the formal specification. 

I propose that the formality of specifi¬ 
cations and designs be developed together 
in box structures with many sponsor and 
user interfaces. Box structures allow the 
stepwise refinement and verification of 
hierarchical system designs from their 
specifications at formal and informal 
levels. 

Long division in place notation is an 
example of a stepwise refinement and 
verification process that produces a quo¬ 
tient and remainder from a dividend and 
divisor. Each major step produces the next 
digit of the quotient by a creative estimate 
of its value followed by an immediate 
verification of its correctness. If the verifi¬ 
cation fails, a new estimate is provided and 
verified. The minor steps are digit-by-digit 
arithmetic operations with no further 
invention beyond estimating the next digit 
of the quotient. Using the fundamental 
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Box structures of data 
abstractions allow the 
stepwise refinement 
and verification of 
hierarchical system 
designs from their 
specifications at 
formal and informal 
levels. 


mathematical discoveries that made long 
division possible, a skilled school child can 
solve problems beyond the capability of 
Euclid and Archimedes. 

Box-structured system design 1 is a step¬ 
wise refinement and verification process 
that produces a system design from a spec¬ 
ification. Such a system design is defined 
by a hierarchy of small design steps that 
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permit the immediate verification of their 
correctness, just as the next digit can be 
verified immediately in long division. 
Three basic principles underlie the box- 
structured design process: 

(1) All data to be defined and stored in 
the design is hidden in data abstractions. 2 
Even program variables define simple data 
abstractions with entries for, say, set and 
query; the set entry with a value ensures 
that any query entry preceding another set 
returns that value. 

(2) All processing is defined by sequen¬ 
tial and concurrent uses of data abstrac¬ 
tions. For example, the simple assignment 
statement x : = y, where x and y name 
program-variable data abstractions, can 
be considered as the sequence of a query 
of y followed by a set of x using the value 
returned by y. 

(3) Each use of a data abstraction in the 
system occupies a distinct place in the 
usage hierarchy. 3 For example, a data 
abstraction for the assignment x: = x + 
y would use the data abstraction for x in 
two distinct ways and show the uses in its 
usage hierarchy. 

These three principles unify the distinc¬ 
tions between system design and program 
design. In particular, Parnas’ usage hier¬ 
archy 3 provides a powerful place notation 
for creating, documenting, and inspecting 
software designs. 
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Figure 1. Black box. 


Program variables and assignment 
statements are especially simple data 
abstractions. Stacks and queues are more 
elaborate, requiring tens or hundreds of 
program declarations and statements. 
Entire systems, such as information or 
database systems containing thousands or 
millions of lines of program source code, 
are also data abstractions, whether cons¬ 
ciously developed as such or not. 

Defining a data abstraction in three 
forms reduces the size of steps required to 
define its structure and use in system 
design. These forms are called the black 
box, state box, and clear box. The black 
box gives an external description of data 
abstraction behavior in terms of usage. 
The state box gives an intermediate 
description in terms of an internal state 
and the use of an internal data abstraction. 
The clear box gives an internal description 
by replacing the state box’s internal data 
abstraction with the sequential or concur¬ 
rent usage of other data abstractions. 

Each major step in box-structure design 
expands a black-box description into a 
state box and then into a clear box. An 
immediate verification of correctness fol¬ 
lows each substep. If a verification fails, 
a new expansion is required. Two points 
of creative invention are required in each 
major step: (1) the encapsulation of usage 
histories into a state box and (2) the 
decomposition of state-box transitions 
into a clear-box process. The verification 
steps are analytic and repeatable without 
invention. 

Usage hierarchies and 
block diagrams 

Block diagrams, such as those found in 
data-flow diagrams, coalesce the uses of 
each data abstraction in the usage hierar¬ 
chy into a single node and coalesce the 
usage relations among data abstractions 
into arcs between nodes. Such diagrams 


irreversibly summarize hierarchical infor¬ 
mation. Mappings from usage hierarchies 
to block diagrams are from many to one 
and mappings from block diagrams to 
usage hierarchies are from one to many. 

Block diagrams used in descriptions 
summarize system structure to aid general 
understanding of a system’s parts and data 
flow among the parts. The parts can be 
decomposed into block diagrams and 
parts hierarchies for a general perspective 
of system structure. 

Block diagrams used in design are con¬ 
ceptions about data flow among modules 
to be designed. Since the mapping from 
block diagram to complete design is from 
one to many, only one or a few designs that 
satisfy a block diagram will be correct. 
Consequently, if the sequential or concur¬ 
rent use of modules shown in block dia¬ 
grams is left as programming details for 
later expansions, then the design process 
is inherently error-prone because the cor¬ 
rectness of use among modules cannot be 
immediately verified. Correct detailed 
program design is even more difficult 
when block diagrams are expanded into 
hierarchies of more-detailed block dia¬ 
grams without defining sequential and 
concurrent uses at each level. 

Box structures of data 
abstractions 

There is a direct relationship between 
object-oriented development and box- 
structured design in the implementation of 
data abstractions as “objects.” 4 In fact, 
box-structured design represents a sys¬ 
tematic process for creating object- 
oriented designs. 

Object-oriented development also uses 
inheritance to describe objects or data 
abstractions. As data abstractions become 
more complex and usage hierarchies 
become deeper, inherited properties can 
dramatically improve the precision of 
descriptions. Such property hierarchies, 
combined with formal methods of axio¬ 
matic and algebraic description, 2 are 
needed to deal with substantial systems in 
an orderly way. 

Black-box descriptions. Stepwise refine¬ 
ment and verification of system design 
describes system behavior entirely in data 
abstractions. Parnas’ principle of infor¬ 
mation hiding distinguishes between con¬ 
crete, visible data storage in a system with 
persistent information and the system’s 
external behavior. 3 Parnas describes sys¬ 


tem behavior by its traces with no refer¬ 
ence to stored data. 5 Hoare also uses 
traces to define system behavior for net¬ 
works of communicating processes. 6 
These ideas lead to a direct, mathematical 
description of system behavior. 

Any realized data abstraction exists in 
real time, whether it performs a so-called 
real-time function or not. Various uses are 
initiated at various entries, possibly con¬ 
currently. It is useful to classify each initi¬ 
ation (defined by the entries and any data 
required) as a stimulus to the abstraction 
and each return (defined by the exits and 
any data produced) as a response by the 
abstraction. Each response is determined 
uniquely by the stimuli it has previously 
received and accepted. That is, for each 
realized data abstraction, there is a mathe¬ 
matical function from its stimulus histo¬ 
ries to its next response. 

Many abstractions do not require spe¬ 
cific real-time behavior, even though each 
realization exists in real time. In such 
cases, the function is defined for sequen¬ 
tially ordered stimuli. For example, a 
finite-stack data abstraction is usually 
described as a sequential process rather 
than a real-time process. 

Figure 1 shows a black box, with a 
stimulus (possibly through multiple con¬ 
current entries) producing a response (pos¬ 
sibly through multiple concurrent exits). 
Let S be the set of possible stimuli and R 
be the set of possible responses. The black¬ 
box description is a mathematical function 
/from the set of sequences on S (call it S*) 
to R of type 

f: S*~* R 

For especially simple data abstractions,/ 
can be given in closed mathematical nota¬ 
tion. For large abstractions, it may be 
necessary to give/in the natural language 
of a problem domain, often a mixture of 
formal and informal language. Whatever 
the notation, the black-box description is 
a function. 

A specification for a data abstraction 
can be given as a set of traces 6 consisting 
of every acceptable sequence of inter¬ 
leaved stimuli and responses. If two sub¬ 
sequences are identical until a stimulus 
produces different responses in each, then 
the specification defines a mathematical 
relation rather than a function. Mathemat¬ 
ical relations can also be used as black 
boxes to describe data abstractions with 
nondeterministic behavior. 

In programming languages that permit 
program variables to be declared but not 
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initialized, data abstractions of the vari¬ 
ables have nondeterministic behavior up to 
the first set stimulus, but deterministic 
behavior after. In programming languages 
that require variable initialization, these 
data abstractions are deterministic. 

State-box descriptions. The term ‘ ‘data 
abstraction” implies the possibility of stor¬ 
ing data between stimuli to respond to the 
effects of previous stimuli. For example, 
in a finite-stack abstraction, a push pro¬ 
vides a data item that may be required as 
a response for some later copy-top opera¬ 
tion. The principle of information hiding 
requires that any such data be regarded as 
part of an abstract state of the data 
abstraction, which may be implemented in 
various ways but always provides a correct 
description of behavior. 

There is a simple mathematical way to 
guarantee the existence of such a state and 
the correct behavior of an abstraction with 
it. Regard the stimulus history itself as the 
state. Then, for each stimulus, use the 
black-box function to compute the 
response from the stimulus history, includ¬ 
ing the stimulus just received. Finally, 
compute the new state by appending that 
stimulus to the previous state. This con¬ 
struction defines a state machine, but not 
a finite-state machine because stimulus 
histories are not bounded. Of course, most 
interesting data abstractions have a func¬ 
tion mapping the unbounded set of stimu¬ 
lus histories to a finite set of new state 
representations that let a finite-state 
machine provide the black-box behavior. 

However, the classical-state machine, in 
which the state machine transition is a 
mathematical function from stimuli and 
old states to responses and new states, has 
one serious deficiency in elaborating sys¬ 
tem behavior in a hierarchical structure. 
Such a transition function forces all state 
data into the state machine’s state, ter¬ 
minating the hierarchy of state data stor¬ 
age. In fact, the implementations of 
complex data abstractions typically con¬ 
tain several levels, with information hid¬ 
den at each level. 

A state box—a simple generalization of 
the idea of a state machine—allows such 
implementations. A state box uses a data 
abstraction to determine the next state and 
response for each stimulus. The abstract 
state can then be distributed in any way 
desired between the state and the transition 
behavior of the state box. A state box is 
pictured in Figure 2, which shows an inter¬ 
nal black box whose stimulus arrives con¬ 
currently from the external stimulus and 


Figure 2. State box. 


the internal state, and whose response 
departs concurrently to the external 
response and the new internal state. 

Let Tbe a set of states. The behavior of 
the state box is given by an initial state t in 
T and function g of the type 

g: S*xr*-- RxT 

that is, a black-box function from stimu¬ 
lus and state histories to the next response 
and state. Each pair < t , g) uniquely 
defines a black-box function/through the 
elimination of intermediate states by 
repeated substitution. 

For example, given (t, g) with ith 
stimulus s.i, stimulus history sh.i = <5.1, 

5.2. s.i ), ith response r. i, state t.i- 1, 

state history th.i-l = <f, 1. 1. 

t.i- 1), and g = (gr, gt) then 

r.i = gr(sh.i, th.i- 1) 
and 

t.i = gt(sh.i, th.i-l) 

Define the state history function gth such 
that 

gth(sh.i, th.i- 1) = </, gt(sh. 1,«», 

. . .,gt(sh.i, th.i-l )> 

By substitution, if /> 1, 

r.i = gr(sh.i, gth(sh.i- 1, th.i-2)) 

If />2, 

r.i = gr(sh.i, gth{sh.i- 1, gth(sh.i-2, 
th.i-3))) ■ 


and, continuing i substitutions, 

r.i = gr(sh.i, gth(sh.i- 1, . . . 
gth(sh. 1, <0). • •)) 

which is a value of a function of type/with 
parameter t. That is, for each state box 
there is a unique black box. Given black¬ 
box functions of type F, state-box func¬ 
tions of type G, and states of type T, there 
exists a mathematical function d of type 

d: TxG~* F 

The values of function d are called the 
black-box derivatives of state boxes. To 
verify that a state box has been designed 
correctly to provide black-box behavior, 
the derived black box need only be com¬ 
pared to the intended black box. 

Clear-box descriptions. The theorems 
and experiences of structured program¬ 
ming lead to a direct definition of four 
kinds of clear boxes: three sequential 
forms for sequence, alternation, and iter¬ 
ation, and one concurrent form. In each 
case, a particular form of sequential or 
concurrent usage of data abstractions is 
defined to replace the internal data 
abstraction of the state box. Alternation 
and iteration use special data abstractions 
called conditions in which the stimulus is 
directed out through one of multiple exits. 
In each use, a regular data abstraction (not 
a condition) accesses and updates the state. 

The definitions in sequential usage are 
familiar. In concurrent usage, the defini¬ 
tions are novel to ensure referential trans¬ 
parency in concurrent and sequential 
usage. The definitions in concurrent usage 
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Figure 3. Sequence Clear Box. The response from B1 becomes the stimulus to B2. 



Figure 4. Alternation Clear Box. The condition black box C directs its stimulus to B1 or B2. 


provide an ordered set of new states and 
responses from each concurrent data 
abstraction, with the requirement that a 
new data abstraction, called Resolve, be 
defined to resolve discrepancies among the 
responses into a single response. 

The four kinds of clear boxes are pic¬ 
tured in Figures 3-6. Their function seman¬ 
tics can be derived directly from the 
semantics of their states and black boxes. 


As in the case of mapping a state box into 
a black box, there is a derivative function 
mapping any clear box into a unique state 
box. To verify that a clear box has been 
designed correctly to provide state-box 
behavior, the derived state box need only 
be compared with the intended state box. 
These verifications can be carried out by 
substitution and case analyses to eliminai 
sequential and concurrent process. 


Realism and rigor in 
software design 

When jointly developing formality in 
specifications and designs, a basic princi¬ 
ple is that the final, formal system will 
have the behavior of a black box function. 
So the behavioral specification should be 
a function or relation at every level of for- 
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mality. The box structures allow any level 
of formality. As formality increases, fal¬ 
libilities and ambiguities can be discovered 
and corrected. 

Sponsors and implementers urgently 
need a coherent account of design activi¬ 
ties. However, the unfolding of a design 
from specifications to computer resources 
requires considerable learning with much 
trial and error. In particular, two formi¬ 
dable problems complicate the design trail. 
Intelligent decision-making at the top level 
requires that various low-level problems be 
assessed and solved in detail. Also, any 
reasonable method must recognize that the 
specification is almost certain to change 
during development. To deal with such 
problems, Parnas advocates a usage hier¬ 
archy of modules, each hiding certain 
secrets, by a joint study of the specification 
in the problem domain and the available 
computing resources, with the probability 
of change explicitly recognized. 3 

Box-structured design leads to the same 
goal as Parnas’ usage hierarchy. Let’s 
assume that the top of a mountain is a for¬ 
mal description and that farther down its 
slopes the descriptions are more and more 
informal (with more and more fallibility). 
I propose a spiral approach to the top 
through several levels of formality. In fact, 



Figure 5. Iteration Clear Box. The condition black box C directs its stimulus to B 
or the external response of the clear box. The response from B becomes the stimu¬ 
lus to C. 



Figure 6. Concurrent Clear Box. The external stimulus is directed to both B1 and B2. The responses from B1 and B2 together 
become the stimulus to Resolve. 
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the climb begins in the language of the 
problem domain—often a lot of 
English—and ends up in the computer 
domain of entirely formal code. Box struc¬ 
tures, whether formally or informally 
described, are used on the way up with 
stepwise refinement and verification. 
Also, advance scouts must move ahead to 
assess and solve problems in low-level 
details with more formality. So, for exam¬ 
ple, Parnas’ ideas about looking for 
appropriate secrets in upcoming data 
abstractions are useful. 

System design by 

box-structure 

expansion 

A box-structure expansion begins with 
a black-box specification of a data abstrac¬ 
tion. It identifies the black box, a state box 
with the same behavior as that of the black 
box, and a clear box with the same 
behavior as that of the state machine, 
using data abstractions at the next level 
with their own black-box behavior. 
Although the theory can be given entirely 
in function theoretical terms with abstract 
states and functions, a practical design 
process must use concrete design and pro¬ 
gramming languages to describe data 
abstractions and their uses. This shift from 
theory to practice involves only a change 
in syntax, not in semantics. A design or 
program is a rule for a function, and data 
descriptions and program structures are 
means for facilitating expression of such 
rules. 

Each expansion of a box structure is a 
step in designing internal state data and 
internal sequential or concurrent process. 
These steps can require considerable 
invention. It helps to break each expansion 
into smaller steps, leaving design trails that 
permit more objective engineering inspec¬ 
tions. For this purpose, I define the follow¬ 
ing 11-step box-structure expansion 
process: 

Define the black box 

(1) Define black-box stimuli 

Determine all possible stimuli 
for the black box. 

(2) Define black-box behavior 

For each possible stimulus, 
determine its complete response 
in terms of its stimulus history. 

Design the state box 

(3) Discover state data requirements 

For each response to be calcu¬ 


lated, encapsulate its stimulus 
history into a state data 
requirement. 

(4) Define the state 

Select a subset of the required 
state data items to encapsulate 
stimulus histories. 

(5) Design the state box 

For the selected state, deter¬ 
mine the internal black box 
required for the state box. 

(6) Verify the state box 

Verify the correctness of the 
state box with respect to the 
required black-box behavior. 

Design the clear box 

(7) Discover state data accesses 

For each item of state data and 
each possible stimulus, deter¬ 
mine all possible accesses of the 
item. 

(8) Define data abstractions 

Organize state data into data 
abstractions for effective 
access. 

(9) Design the clear box 

Define sequential or concurrent 
uses of the data abstractions 
defined to replace the internal 
black box of the state box. 

(10) Verify the clear box 

Verify the correctness of the 
clear box with respect to the 
state-box behavior. 

Continue the process 

(11) Repeat stepwise expansion until 
design completion 

For each new data abstraction, 
repeat steps 1-10 until suitable 
data and program specifica¬ 
tions are reached. 

The inventions required in this process 
are strictly contained in steps 4, 5, 8, and 
9 and labeled there. The other steps are 
analytic and repeatable. This process iso¬ 
lates and embeds the creative design steps, 
allowing design reviews in canonical cases 
and automatically developing relevant 
information while leading up to each step. 
For example, step 3 provides enough back¬ 
ground to carry out step 4 and review it 
objectively. 

In contrast, heuristic approaches often 
skip these analytic steps and leap to net¬ 
works of sources, processes, stores, and 
sinks. However, in large problems, it is dif¬ 
ficult and sometimes painful to determine 
if a leap was inspired or flawed. The com¬ 
plexity and the number of design alterna¬ 


tives make it risky to leap that 
discontinuity without a lot of engineering 
analysis. 

A navigation and 
weather buoy case 
study 

Booch uses the problem of a navigation 
and weather buoy to illustrate a data-flow 
approach to object-oriented architecture 
and design. 4 The problem was redone in 
box structures as shown below. (I subse¬ 
quently learned that this problem was 
originally suggested by Chmura et al. 7 
with a solution in terms of a set of 
information-hiding modules. The solution 
below was developed without knowledge 
of Chmura’s solution.) Booch gives the 
following statement of the problem. 

The Host at Sea system is a group of 
free-floating buoys that provide naviga¬ 
tion and weather data to air and ship traf¬ 
fic. The buoys collect data on air and water 
temperature, wind speed, and location 
through sensors. Each buoy can have a 
different number of sensors and can be 
modified to support other types of sensors. 

Each buoy is also equipped with a radio 
transmitter (to broadcast weather and 
location information as well as an SOS 
message) and a radio receiver (to receive 
requests from passing vessels). A sailor can 
flip a switch on the buoy to initiate an SOS 
broadcast and some buoys are equipped 
with a red light that can be activated by a 
passing vessel during search operations. 
Software for each buoy must: 

• Maintain current average wind, tem¬ 
perature, and location information. Wind 
speed readings are taken every 30 seconds, 
and temperature and location readings are 
taken every 10 seconds. Wind and temper¬ 
ature values are kept as a running average. 

• Broadcast wind, temperature, and 
location information every 60 seconds. 

• Broadcast wind, temperature, and 
location information from the past 24 
hours in response to requests from passing 
vessels. This takes priority over the peri¬ 
odic broadcast. 

• Activate or deactivate the red light 
based on a request from a passing vessel. 

• Continuously broadcast an SOS sig¬ 
nal after a sailor engages the emergency 
switch. This signal takes priority over all 
other broadcasts and continues until reset 
by a passing vessel. 

On the basis of this problem statement, 
Booch invented a data-flow diagram and 
identified objects, attributes, and opera- 
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tions for an object-oriented architecture 
for such a buoy. 4 However, the 11-step 
expansion process outlined above yields a 
different architecture. 

Preliminary black-box analysis. The 
data-flow approach jumps right in with 
various internal flows and processes to 
solve the problem. The box-structure 
approach focuses first on defining the 
problem as a real-time transformation of 
stimuli to responses. The problem state¬ 
ment identifies the following general types 
of stimuli: 

• clock data (various references to time) 

• wind data 

• temperature data 

• location data 

• request to broadcast 24 hours of 
weather data 

• request to activate or deactivate a red 
light 

• request to start or stop continuous 
SOS broadcast 

Members of these stimulus types may 
arrive concurrently in various combina¬ 
tions to make up a stimulus. 

The problem statement further identi¬ 
fies possible responses to these stimuli as 

• start or stop continuous SOS 
broadcast 

• activate or deactivate the red light 

• start a broadcast of 24 hours of 
weather data 

• start a broadcast of current weather 
data 

Since there is only one transmitter, start¬ 
ing a broadcast means stopping any other 
broadcast currently under way. 

The rest of the problem statement gener¬ 
ally indicates which response should fol¬ 
low any possible stimulus. The response 
depends on the stimuli accumulated to the 
moment, through references to running 
averages. So the buoy’s black box will 
require histories of certain stimuli cover¬ 
ing more than 24 hours (for example, a 
24-hour-old running average will require 
data more than 24 hours old). 

Data must be encapsulated in any state 
box for this black box. References to run¬ 
ning averages of wind and temperature 
data suggest that new data abstractions 
can greatly simplify the necessary compu¬ 
tations and data management. However, 
before rushing into architecture and design 
decisions on internal data flows and pro¬ 
cesses, it is worthwhile to focus more 
attention on the problem. 

Questions about the problem statement. 

This preliminary black-box analysis shows 


A black box is a 
formal specification 
that is complete, 
unambiguous, and 
consistent. 


that the problem statement is far from a 
specification. Many additional decisions 
are needed to remove ambiguities, ensure 
completeness and consistency, and pro¬ 
vide a solution without unpleasant sur¬ 
prises for the buoy’s sponsors and users. 
Such problems should be tackled at the 
black-box level before plunging into state- 
box and clear-box expansions. 

Obviously absent from the problem 
statement is how the buoy is to be oper¬ 
ated. While the buoy could be developed 
as an expendable device that is deployed 
and left alone, whoever is responsible for 
its operation might want more control (for 
example, to monitor system integrity, 
security, or correctness through testing or 
diagnostics). If so, additional types of 
stimuli and responses must be defined. 

This example assumes the buoy is 
expendable. However, note that a focus on 
immediate users, to the exclusion of secon¬ 
dary users such as operators and main- 
tainers, usually leads to faulty designs that 
can only be patched up enough to become 
poor designs. 

Also absent from the problem statement 
are questions involving initialization: 

• Is the periodic weather broadcast 
(every 60 seconds) tied to Greenwich Mean 
Time (GMT) or to an internal clock that 
will appear random in real time to its 
users? 

• What is expected if a 24-hour-weather 
broadcast is requested before enough data 
have been collected since the start (or 
restart) of the buoy’s operation? 

• Can the operators restart the buoy 
(for example, after moving it to another 
location in an emergency situation)? 

• How are the running averages to be 
initialized? 

The problem statement mentions that 
SOS broadcasts and 24-hour-weather 
broadcasts have priority, but that raises 
more questions: 

• Does a lower-priority broadcast abort 


when a higher-priority one is requested, or 
does it finish first? 

• Can a 24-hour request abort another 
24-hour request? 

Other questions to be addressed at this 
stage include 

• What is the exact content of a current- 
weather broadcast? Of a 24-hour-weather 
broadcast? 

• How many samples are needed for 
running averages, and can that parameter 
be controlled by the operators? 

• Is the running average of wind a vec¬ 
tor average? 

Completing the problem statement. A 

black-box analysis forces the identification 
of every possible stimulus of the buoy and 
every acceptable response in terms of the 
stimulus history. The principle of transac¬ 
tion closure 1 requires that any informa¬ 
tion needed to produce a response be 
provided by some previous stimulus. For 
example, a weather broadcast requires 
previous wind and temperature data. 

A black box is a formal specification 
that is complete, unambiguous, and con¬ 
sistent because it is a mathematical func¬ 
tion or relation from all possible stimulus 
histories to responses, whether it is repre¬ 
sented in mathematical notation, English, 
or a mixture of the two in the problem 
domain. Completion of a black-box anal¬ 
ysis and description usually requires many 
interactions with sponsors and users. 
However, getting a good specification is 
far less expensive over the life cycle than 
launching into design and implementation 
without knowing what the sponsors had in 
mind or the users needed. 

In this case study, let us assume the fol¬ 
lowing resolutions to the previous 
questions: 

• The buoy clock and sensors are 
restarted at the next GMT minute mark 
after the moment of restart. 

• The phrase “24-hour-weather broad¬ 
cast” means “weather-since-restart broad¬ 
cast” if restart was less than 24 hours ago. 

• A buoy can be restarted or shut down 
at any time by the use of a password, with 
restart conditions for its location and 
running-average parameters. The pass¬ 
word can be changed by use of the current 
password; the initial password is “buoy.” 
The password is unchanged by a restart or 
shutdown. 

• A request for SOS broadcast 
preempts and aborts any other broadcast. 

• A periodic weather broadcast is can¬ 
celled if any other broadcast is under way. 
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• A request for 24-hour-weather broad¬ 
cast is ignored if an SOS broadcast is under 
way. It is queued to follow a periodic 
current-weather broadcast or 24-hour- 
weather broadcast if one of these is already 
under way. Otherwise, it is granted 
immediately. 

• The exact content of a current- 
weather broadcast is the current location, 
running average of wind, and running 
average of air and water temperatures. A 
24-hour-weather broadcast contains the 
current-weather broadcasts for each of the 
previous 24 GMT hour marks (or all GMT 
hour marks if restart was less than 24 hours 
ago). 

• The number of samples in running 
averages for wind and temperature is 
defined by integer parameters set at restart 
or by default. The term “running aver¬ 
age” means “average since restart.” 

• The running average of wind is the 
running average of the wind vector. 

In practice, these resolutions should be 
further scrutinized by sponsors, users, and 
analysts, and the entire problem state- 
ment/black box should be cast into a more 
systematic problem-domain statement for 
formal review and concurrence by spon¬ 
sors and users. 

The result is a mathematical function or 
relation from all possible stimulus histo¬ 
ries to responses, in which transaction clo¬ 
sure is obtained. This function or relation 
must deal specifically with the response to 
the first stimulus, the second, the third, 
and so on, even though it is tempting to 
focus on steady-state operations far 
removed from initial conditions. 

Stepwise box-structure 
expansion of the buoy 
problem 

Step 1. Define black-box stimuli. The 

second round of the problem statement 
analysis gave the buoy a restart capability 
that obviates all history except the current 
password. Such a restart capability is 
usually needed for operational control, no 
matter how well the device was thought 
out. 

The physical media for stimulus types 
include clock and sensor connections, 
radio receptions, and mechanical switches. 
Let us suppose the buoy has a basic inter¬ 
nal clock that polls the digitized informa¬ 
tion and is accurate enough to deal with the 
sensors and the radio transmitter and 
receiver. Let us also assume that a “start 


Sponsors, users, and 
analysts must 
determine the 
response from every 
possible stimulus 
history. 


broadcast” command is available and that 
the transmitter returns a “broadcast ter¬ 
minated” signal. 

Because of the need to maintain GMT, 
let us suppose the clock is synchronized to 
GMT by means outside the scope of this 
study and that the basic periodic clock 
pulse generated is present in every stimu¬ 
lus. The possible stimulus types are 

• clock pulse, 

• restart command and data, 

• shutdown command, 

• change password command and data, 

• wind data, 

• air temperature data, 

• water temperature data, 

• location data, 

• request to broadcast 24 hours of 
weather data, 

• request to activate a red light, 

• request to deactivate a red light, 

• request to start continuous SOS 
broadcast, 

• request to stop continuous SOS 
broadcast, and 

• broadcast terminated. 

Thus, there are 14 possible stimulus 
types present in every stimulus. The clock 
pulse is always present and the others are 
present independently of each other. Seven 
of these types contain data, but seven do 

Some types conflict in their effects. For 
example, a vessel may send a request to 
stop continuous SOS broadcast due to its 
handling of one emergency at the same 
time a sailor pushes the switch to start an 
SOS broadcast for another emergency. 
The black box must describe the response 
to this presumably unusual case. In fact, 
the information developed in the interac¬ 
tion between sponsors, users, and analysts 
must determine the response from every 
possible stimulus history, whether 
expected frequently or infrequently. 

Step 2. Define black-box behavior. As 

derived above, the domain for the black 
box (function) is the set of all possible his¬ 


tories of stimuli with one to 14 members of 
these stimulus types. That is an infinite 
domain, but with a simple structure. For¬ 
tunately, the interactions between these 
stimulus types are also simple. 

The function mapping from these 
stimulus histories to responses is simple 
enough to decompose the effects of stimu¬ 
lus types to a few cases, many quite 
autonomous for the stimulus type 
involved. This is shown in Figure 7, where 
the response required is denoted by R. The 
response required for each stimulus type 
is given in Box Description Language 1 for 
readability by sponsors, users, and 
analysts. The outer syntax is formal 
(denoted in Figure 7 in uppercase charac¬ 
ters), but the inner syntax is informal for 
now. 8 The informal expressions in inner 
syntax should be replaced by more formal 
expressions as the design progresses. 

Note that the responses in Figure 7 are 
described entirely in terms of stimulus his¬ 
tories. The phrase “broadcast is under 
way” looks suspiciously like a status, but 
is used as shorthand for “broadcast previ¬ 
ously started with no subsequent broad¬ 
cast termination stimulus.” "Broadcast 
has been requested” is shorthand for 
“broadcast previously requested with no 
subsequent broadcast started. ” It is some¬ 
times convenient to use response history 
(such as broadcast started) as proper short¬ 
hand in a black-box description because 
any such response can be determined from 
previous stimulus history. 

The actions in Figure 7 are limited to 
responses without presuming internal 
activity. For example, statement 9, in 
response to a request to broadcast 24 hours 
of weather data, responds only if no 
broadcast is under way. If a broadcast is 
under way, one might expect some inter¬ 
nal action to note the request for later 
response, but statement 9 takes no such 
action. However, statement 1 deals with 
this situation by checking stimulus histo¬ 
ries for requests that can be responded to 
at each clock pulse. The principle is to deal 
only with responses specified by stimulus 
histories, not to begin inadvertently 
inventing internals. 

Note that several stimulus types are 
accepted during shutdown, namely restart 
command and data, request to activate or 
deactivate red light, request to start or stop 
SOS broadcast, all sensor stimuli, and 
broadcast termination. These are decisions 
about specifications as well as design if 
they have not been explicitly defined. In 
fact, the black box will define a specifica¬ 
tion that the sponsors and users should 
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1 . 

clock pulse 

R: IF no shutdown command since last restart 
command 

6. 

air temperature data 

R: acknowledge data. 


THEN 

IF no broadcast is under way AND a 
24-hour-weather broadcast has been 

7. 

water temperature data 

R: acknowledge data. 


requested 

THEN form and start 24-hour- 
weather broadcast 

8. 

location data 

R: acknowledge data. 


ELSE 

IF GMT is at the minute mark 

THEN form and start current- 
weather broadcast. 

9. 

request to broadcast 24 hours of weather data 

R: IF no shutdown command since last restart 
command 

THEN 

IF no broadcast is under way 

2. 

restart command and data 

R: IF password correct 

THEN confirm restart. 

10. 

THEN form and start 24-hour- 
weather broadcast. 

request to activate red light 

3. 

shutdown command 

R: IF no shutdown command since last restart 


R: activate red light. 


command 

THEN 

IF password correct and no restart 
command 

11. 

request to deactivate red light 

R: IF no request to activate red light 

THEN deactivate red light. 

4. 

THEN confirm shutdown. 

change password command and data 

12. 

request to start continuous SOS broadcast 

R: start continuous SOS broadcast. 


R: IF no shutdown command since last restart 
command 

THEN 

IF password correct and no restart or 

13. 

request to stop continuous SOS broadcast 

R: IF no request to start SOS broadcast 

THEN stop continuous SOS broadcast. 

5. 

shutdown command 

THEN confirm password change. 

wind data 

R: acknowledge data. 

14. 

broadcast termination 

R: acknowledge termination. 


Figure 7. Black-box responses for buoy. 


understand in confirming previous agree¬ 
ments on what is required of the system. 

Step 3. Discover state data require¬ 
ments. The next step is to determine the 
information needed to encapsulate stimu¬ 
lus histories to be maintained from one 
stimulus to the next, so no previous stimu¬ 
lus is required to determine the response. 
There is a simple necessary and sufficient 
condition for this encapsulation: 

• The responses define the necessary 
information to be maintained in the state 
box. 


• The history of stimuli contains suffi¬ 
cient information for the state box. 

That is, a satisfactory encapsulation of his¬ 
tory into the state and internal black box 
of the state box can be derived directly 
from the black box. 

To provide a convenient design trail for 
engineering inspections of the buoy, I 
expand the listing of stimulus types and 
responses in Figure 7 into state data that 
encapsulates the necessary histories, as 
shown in Figure 8. The encapsulation fol¬ 
lows directly from an examination of the 
responses and their dependency on stimu¬ 


lus histories. 

For example, in the clock pulse stimu¬ 
lus type, the condition “no shutdown 
command since the last restart command” 
must be encapsulated because it depends 
on stimulus history. Let us encapsulate it 
in “buoy status,” an invented term for a 
derived requirement, and suppose that 
buoy status is on only if there has been no 
shutdown command since the last restart 
command. Similarly, the condition “no 
broadcast is under way” can be encapsu¬ 
lated in “broadcast status,” and 
“24-hour-weather broadcast has been 
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1 . 

clock pulse 

R: IF no shutdown command since last restart 
command 

THEN 

6. 

air temperature data 

R: acknowledge data. 

E: none 


IF no broadcast is under way AND a 
24-hour-weather broadcast has been 
requested 

THEN form and start 24-hour- 

7. 

water temperature data 

R: acknowledge data. 

E: none 


weather broadcast 

ELSE 

IF GMT is at the minute mark 

THEN form and start current- 

8. 

location data 

R: acknowledge data. 

E: none 


weather broadcast. 

E: buoy status, broadcast status, broadcast- 

request status, 24-hour weather history, clock 
time, location, wind history, air temperature 
history, water temperature history 

9. 

request to broadcast 24 hours of weather data 

R: IF no shutdown command since last restart 
command 

THEN 

IF no broadcast is under way 

THEN form and start 24-hour- 

2. 

restart command and data 

R: IF password correct 

THEN confirm restart. 


weather broadcast. 

E: broadcast status, 24-hour weather history 


E: password, restart state. 

10. 

request to activate red light 

R: activate red light. 

3. 

shutdown command 

R: IF no shutdown command since last restart 


E: none 


command 

THEN 

IF password correct and no restart 
command 

THEN confirm shutdown. 

11. 

request to deactivate red light 

R: IF no request to activate red light 

THEN deactivate red light. 

E: none 


E: password, shutdown state 

12. 

request to start continuous SOS broadcast 

R: start continuous SOS broadcast. 

4. 

change password command and data 

R: IF no shutdown command since last restart 


E: none 


command 

THEN 

IF password correct and no restart or 
shutdown command 

THEN confirm password change. 

13. 

request to stop continuous SOS broadcast 

R: IF no request to start SOS broadcast 

THEN stop continuous SOS broadcast. 

E: none 


E: password 

14. 

broadcast termination 

R: acknowledge termination. 

5. 

wind data 

R: acknowledge data. 

E: none 


E: none 


Figure 8. Derivation of encapsulated data for buoy. 


requested” can be encapsulated in 
“broadcast-request status.” In Figure 8, 
encapsulated data is denoted by E. 

Note that these state data requirements 
are derived from the responses of the black 
box, not the stimuli. For example, the 
stimulus types for wind and temperature 


data require only acknowledgment of such 
data, not retention. The need to encapsu¬ 
late wind and temperature data in the state 
box comes from the response “form and 
start current-weather broadcast.” In sum¬ 
mary, the encapsulated data requirements 
are 


• buoy status, 

• broadcast status, 

• broadcast-request status, 

• 24-hour weather history, 

• clock time, 

• location, 

• wind history, 
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• air temperature history, 

• water temperature history, 

• password, 

• restart state, and 

• shutdown state. 

Step 4. Define the state. The identifica¬ 
tion of state data requirements is a first 
design step. However, all such data are 
candidates for migration into lower-level 
box structures. For example, the four his¬ 
tory types in the above list appear to be log¬ 
ical candidates for migration, since they 
will each require considerable storage and 
processing to meet the buoy’s needs. Also, 
restart state and shutdown state are can¬ 
didates for migration because each 
appears in only one statement. The 
remaining data items are scalar and can 
make up the state for the buoy state box. 
Decisions on the migration of encapsu¬ 
lated data are reversible if further analy¬ 
sis uncovers a better strategy. 

Step 5. Design the state box. Steps 3 and 
4 derive state data from the black box by 
rewriting the responses in Figure 7 in terms 
of state data and appending the state tran¬ 
sitions required for the state box. These 
responses and transitions are shown in Fig¬ 
ure 9. For each stimulus type, the response 
and transition is denoted by RT. In Box 
Description Language, CON/NOC 
brackets concurrent statements separated 
by commas. 

Note the internal action in statement 9 
that turns broadcast-request status on if 
the response is to be handled later, in con¬ 
trast with statement 9 of the black box. 

Step 6. Verify the state box. To verify 
the state box, the state data must be elimi¬ 
nated to obtain a derived black box, which 
then must be compared with the intended 
black box. The derivation for this state box 
is quite direct at the level of description 
given. 

For example, the clock pulse RT state¬ 
ment in Figure 9 begins 

IF buoy status on 

while the clock pulse R statement in Fig¬ 
ure 7 begins 

IF no shutdown command since last 

restart command 

which must be verified as equivalent. In 
this case. Figure 9 shows that buoy status 
is set only by the restart command and 
shutdown command. Since the restart 


The outline of the 
verification can be a 
reminder and guide 
for the formal design 
and verification. 


command only sets buoy status on and the 
shutdown command only sets buoy status 
off, eliminating the state data in the con¬ 
dition “buoy status on” reduces to any 
stimulus history in which “no shutdown 
command since last restart command” 
holds. Therefore, the two IF statements 
from the black box and state box begin 
with equivalent conditions. 

Broadcast status and broadcast-request 
status can be treated similarly to buoy sta¬ 
tus. The systematic elimination of state 
data in Figure 9 to derive a black box to 
compare with Figure 7 may seem like a 
rather detailed effort at this point, but it 
builds a solid foundation for continuing 
the design, even on an informal basis such 
as this. 

The alternative to this detailed analysis 
is to leave the high-level control properties 
defined by these three state items to later 
programming details, which cannot be 
verified as design decisions, and leave the 
actual design to people who may not com¬ 
prehensively understand the system 
requirements. However, in system design, 
every level of decomposition must be con¬ 
trolled by a few details that should be iden¬ 
tified and verified immediately. 

Figure 9 should contain enough infor¬ 
mation to verify the correct use of state 
data to meet the requirements of black-box 
behavior in Figure 7. If this verification 
cannot be carried out, even informally, the 
state box is not completely defined. 

In a completed design in a formal lan¬ 
guage, the derivation will take on the 
character of a formal engineering analysis 
of the designed state box to determine the 
derivative black box for comparison with 
a formal black-box specification. This 
engineering analysis is defined in the func¬ 
tion theoretical proof that a state box has 
a unique black-box derivative. But even at 
the informal level described here, the out¬ 
line of the verification can be a reminder 
and guide for the formal design and verifi¬ 
cation. 


Step 7. Discover state data accesses. The 
previous lists and Figures 7, 8, and 9 can 
be used to cross reference all possible 
accesses to this data in various stimulus 
types. For example, buoy status data will 
be captured in certain stimuli and the anal¬ 
ysis shows the necessity of their retention 
in state data. These cross references are 
given in Figure 10. For each state data 
requirement item, every stimulus type that 
could or should access it is listed. For each 
such type, every type of action related to 
the items is also listed. For convenience, I 
identify each access as an update or use. 
Data must be updated before being used, 
so further study is indicated if analysis 
shows no update. 

Step 8. Define data abstractions. Access 
and storage of the 12 data items listed in 
Step 3 have been represented explicitly in 
the state or in data abstractions at lower 
levels. Figure 8 shows every access by every 
stimulus type, providing a basis to derive 
the black boxes required for a clear-box 
design at this level. Six of these objects rep¬ 
resent scalar variables in the state: 

• buoy status 

• broadcast status 

• broadcast-request status 

• clock time 

• location 

• password 

while four represent histories to be 
migrated as common services to new data 
abstractions: 

• 24-hour weather history 

• wind history 

• air temperature history 

• water temperature history 

and two are complete buoy states to be 
migrated down in the clear box to be 
designed: 

• restart state 

• shutdown state 

The response requirements on these 
common data abstractions determine their 
forms. For example, “24-hour weather 
history response” is a sequence of current- 
weather records, each consisting of a GMT 
hour mark, location, wind average, air 
temperature average, and water tempera¬ 
ture average, with a maximum of 24 ele¬ 
ments in the list. However, the only use of 
wind average and air and water tempera¬ 
tures (in current-weather broadcast) calls 
for a running average, so these histories 
can be migrated and encapsulated into 
abstractions whose only data responses are 
running averages. 


June 1988 


33 






1. clock pulse 

RT: IF buoy status on 
THEN 
CON 

update clock, 

IF broadcast status off AND 
broadcast-request status on 
THEN 
CON 

form and start 24-hour- 
weather broadcast, 
set broadcast status on, 
set broadcast-request status 
off 

NOC 

ELSE 

IF clock time is at the minute mark 
THEN 
CON 

form and start current- 
weather broadcast, 
set broadcast status on 
NOC 

NOC 

2. restart command and data 

RT: IF password in stimulus = password 
THEN confirm restart 

3. shutdown command 
RT: IF buoy status on 

THEN 

IF password in stimulus = password 
AND no restart command 
THEN confirm shutdown 

4. change password command and data 
RT: IF buoy status on 

THEN 

IF password in stimulus = password 
AND no restart or shutdown 
command 
THEN 
CON 

confirm password change, 
update password 
NOC 

5. wind data 

RT: acknowledge data 

6. air temperature data 
RT: acknowledge data 


7. water temperature data 
RT: acknowledge data 

8. location data 
RT: CON 

acknowledge data, 
update location 
NOC 

9. request to broadcast 24 hours of weather data 
RT: IF buoy status on 

THEN 

IF broadcast status off 
THEN 
CON 

form and start broadcast, 
set broadcast status on 
NOC 
ELSE 

set broadcast-request status on 

10. request to activate red light 
RT: activate red light 

11. request to deactivate red light 

RT: IF no request to activate red light 
THEN deactivate red light 

12. request to start continuous SOS broadcast 
RT: IF broadcast status not SOS 

THEN 

CON 

start continuous broadcast, 
set broadcast status on 
NOC 

13. request to stop continuous SOS broadcast 
RT: IF no request to start SOS broadcast 

THEN 

CON 

stop SOS broadcast, 
set broadcast status off 
NOC 

14. broadcast termination 
RT: CON 

acknowledge termination, 
set broadcast status off 
NOC 


Figure 9. State-box responses and transitions for buoy. 
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buoy status 

• in clock pulse 

use to test if buoy on 

• in restart command and data 

update as part of restart state 

• in shutdown command 

use to test if buoy on 

update as part of shutdown state 

• in change password command and data 

use to test if buoy on 

• in request to broadcast 24 hours of weather data 

use to test if buoy on 

• in broadcast termination 

use to test if buoy on 

broadcast status 

• in clock pulse 

use to test if no broadcast under way 
update at start 24-hour-weather broadcast 
update at start current-weather broadcast 

• in restart command and data 

update as part of restart state 

• in request to broadcast 24 hours of weather data 

update at start 24-hour-weather broadcast 

• in request to start continuous SOS broadcast 

update at start continuous broadcast 

• in request to stop continuous SOS broadcast 

update at stop continuous broadcast 

• in broadcast termination 

update at broadcast termination 

broadcast-request status 

• in clock pulse 

use to test if 24-hour broadcast has been 
requested 

update at start 24-hour-weather broadcast 


• in restart command and data 

update as part of restart state 

• in request to broadcast 24 hours of weather data 

use to test if broadcast is under way 
update at start 24-hour-weather broadcast 

4. clock time 

• in clock pulse 

update every clock pulse 

use to test if GMT is at the minute mark 

use to test if GMT is at the hour mark 

• in restart command and data 

update as part of restart state 

5. location 

• in clock pulse 

use in current-weather broadcast 

• in restart command and data 

update as part of restart state 

• in location data 

update with location data 

6. password 

• in start command and data 

use to test if password correct 

• in shutdown command 

use to test if password correct 

• in change password command and data 

use to test if password correct 
update with new password 


Figure 10. Encapsulated data analysis table for buoy. 


Step 9. Design the dear box. The dear- 
box expansion of the state machine is quite 
direct at this point. The responses and 
transitions in Figure 9 lead directly to a 
clear box of 14 concurrent black boxes— 
one for each stimulus type—in which each 
black box recognizes its own stimulus type 
in the current complex stimulus and 
responds accordingly. Certain black boxes 
must also recognize other stimulus types. 
For example, the shutdown-command 
black box must check for the absence of a 
restart command before shutting down the 
system. Also, the clock-pulse black box 
must identify the stimulus type “request to 
broadcast 24 hours of weather data.” 


These 14 concurrent black boxes are 
shown as part of Figure 9. 

The Resolve black box required for this 
concurrent clear box must resolve possible 
conflicts in the broadcast responses and 
the values set for buoy status, broadcast 
status, and broadcast-request status. In 
this case, the conflicts can be resolved as 
follows: 

R: accept any response of change in 
state data except for response 
broadcasts, buoy status, 
broadcast status, and 
broadcast-request status, 
which are to be resolved as 
follows: 


response broadcast: 
select in priority order— 
SOS broadcast, 
24-hour-weather broad¬ 
cast, current-weather 
broadcast, no broadcast 
buoy status: on 
broadcast status: based on 
response broadcast 
broadcast-request status: on 

Step 10. Verify the clear box. To verify 
the clear box, the sequential and concur¬ 
rent process must be eliminated to obtain 
the derived state box, which then must be 
compared with the intended state box. The 
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derivation is quite direct for this clear box 
because its concurrent black boxes 
respond to different stimulus type values. 
The Resolve black box defines the priori¬ 
ties and conflict resolutions among the 
concurrent black boxes as already identi¬ 
fied. Immediate verification again pro¬ 
vides direct control over the eventual 
behavior of the system. 

One possible issue here is the responses 
to other stimulus types at restart or shut¬ 
down. The derived state box will provide 
responses to sensors and various requests 
for service that may be counter to the spirit 
of the problem. For example, if a shut¬ 
down command and a request to broad¬ 
cast 24 hours of weather data arrive 
concurrently, the derived state box may 
both confirm a shutdown and form and 
start the broadcast, possibly a questiona¬ 
ble response. A review of the intended 
state box shows that this clear-box 
behavior meets the state-box require¬ 
ments. So, the state box itself should be 
questioned, which leads back to the black 
box from which the expansion began. In 
fact, this may be a desirable way to shut 
down, but it should be resolved and 
documented in black-box behavior. The 
stepwise refinement and verification pro¬ 
cess leaves a design trail for such recon¬ 
siderations, with enough documentation 
to maintain consistency between specifica¬ 
tions and design. 

Step 11. Repeat stepwise expansion until 
design is complete. The new common 
services—24-Hour Weather History, 
Wind History, Water Temperature His¬ 
tory, and Air Temperature History—are 
also subject to systematic design with the 
stepwise box-structure expansion process. 

For example, in order to relocate 
weather data into a new abstraction called 
24-Hour Weather History, its black-box 
stimuli and responses must be determined. 
The abstraction’s main purpose is to 
return a 24-hour weather history on 
demand for the 24-hour-weather broad¬ 
cast. Consequently, a query stimulus is 
needed. Also, weather data including 
GMT, location, wind average, and air and 
water temperature averages must be 
acquired hourly. Call this a data stimulus. 
And, because the buoy can be restarted, a 
restart stimulus is also needed. This infor¬ 
mation is captured formally as follows: 

Black-box stimulus types. 

(1) restart 

(2) data (GMT, location, wind aver¬ 
age, air temperature average, 


water temperature average) 

(3) query 

Black-box responses. 

(1) restart 

R: acknowledge restart. 

(2) data (GMT, location, wind aver¬ 
age, air temperature average, 
water temperature average) 

R: acknowledge data. 

(3) query 

R: last 24 or fewer records of 
weather data received since last 
restart stimulus. 

If this expansion were continued, the 
state data required for the state box would 
be derived using the necessary and suffi¬ 
cient condition for the encapsulation of 
history into state. As before, the listing of 
stimulus types and responses would be 
expanded one more step. The expansion is 
simple in this case, but it provides a design 
trail for engineering inspections as part of 
the overall design of the buoy. 

S tepwise refinement and verifica¬ 
tion in the box structures of data 
abstractions provides a systematic 
discipline for complex system design at any 
level of formality. Once the black box is 
understood as a mathematical function 
from stimulus histories to responses, the 
derivation of state data requirements 
becomes a very direct analysis process sub¬ 
ject to rigorous engineering inspections. 
The identification of state boxes to encap¬ 
sulate state data and processes at the next 
level is also a very direct process. Since 
data abstractions are used at the next level, 
their restatement as black boxes defines 
their behavior, from which state data and 
even lower-level box structures can be der¬ 
ived and inspected systematically. Unlike 
heuristic invention, this derivation is 
repeatable, allowing engineering inspec¬ 
tions because the products and the steps in 
deriving them are familiar to the 
inspectors. □ 
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System and Application 
Software for the Armstrong 
Multiprocessor 

James T. Rayfield and Harvey F. Silverman 
Brown University 


A t any given time, certain applica¬ 
tions are too slow to run on con¬ 
temporary hardware. For 
obvious reasons, parallel processing has 
long been seen as a means of increasing 
computer speed. No matter how fast a 
serial computer can operate, a parallel 
processor incorporating many of the 
fastest serial computers should be faster; 
thus, no advance in serial processing can 
eliminate this advantage. For this reason, 
investigators should seek ways to combine 
many serial computers for performing use¬ 
ful work. 

Problems with parallel¬ 
processing systems 

Most programming languages (and thus 
most programs) assume a uniprocessor 
model: a computer with one processor and 
one memory. Since parallel processors, or 
multiprocessors, have more than one 
processor and often more than one mem¬ 
ory, they cannot run programs designed 
for uniprocessors. Thus, either some way 
must be found to convert uniprocessor- 
model programs to multiprocessor-model 
programs automatically, or programs 
must be written using a multiprocessor 
model in the first place. 

Most multiprocessor systems can be 
modeled as shared-memory systems or 


Among the unique 
features of the 
Armstrong system are 
a reconfigurable I/O 
topology and extensive 
support for message 
passing. 


local-memory systems. Generally speak¬ 
ing, in shared-memory systems all system 
memory appears to be shared by all 
processors in the system. 1 This allows 
cooperating programs on different proces¬ 
sors to share data easily, as long as care is 
taken to ensure synchronization. For 
example, different parts of an array can be 
manipulated simultaneously by different 
processors. Communication between 
processors is implicit in that any altered 
variable can be accessed immediately by all 
other processors. Such systems are often 
referred to as tightly coupled, since com¬ 
munication time between processors is 

0018-9162/88/0600-0038$0!.00©1988 IEEE 


very fast (on the same order as the 
memory-access time). 

At the other extreme, in local-memory 
systems no memory is shared between 
processors. 2 ' 4 Any communication 
between processors occurs over a commu¬ 
nications network. If one processor needs 
the results of another processor’s compu¬ 
tation, the latter must explicitly send the 
result to the former. Such systems are 
often referred to as loosely coupled, since 
the communication time between proces¬ 
sors is usually measured in milliseconds 
(very slow compared with memory-access 
times). Naturally, some systems include 
characteristics of both categories. 5 

With a small number of processors (per¬ 
haps ten), shared-memory systems can 
work very well. Many people find them 
easier to program than local-memory sys¬ 
tems because of the implicit communica¬ 
tion. A programmer does not have to 
remember to send results from processor 
to processor, only to make sure that results 
are calculated before they are needed. The 
problem with shared-memory systems is 
that memory system access times are com¬ 
parable to the speed of processor technol¬ 
ogy, and no current memory technology 
allows concurrent access by more than two 
or three processors. Thus, memory paral¬ 
lelism cannot be expanded as the number 
of processors increases. With a large num¬ 
ber of processors, performance degrades 
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rapidly, although the number of proces¬ 
sors can be increased by using some local 
memory while simulating shared memory 
with caching techniques. 

Local-memory systems do not suffer 
directly from this memory contention 
problem. Since each processor has hard¬ 
ware communicating with one or more 
other processors, the number of possible 
simultaneous “conversations” increases in 
proportion to the number of processors. 
Thus, local-memory systems can have 
many processors. However, these systems 
have several disadvantages. First, not 
every processor can communicate directly 
with every other processor, since this 
would result in a communications network 
with complexity proportional to P 2 , 
where P is the number of processors in the 
system. Since for the most part this is 
impractical, an incomplete communica¬ 
tions network must be used. Thus, com¬ 
munication between processors is often 
indirect, with data passing through inter¬ 
mediate processors. This increases com¬ 
munication delay and generally decreases 
throughput. In addition, the necessity for 
explicit communication increases software 
complexity and may reduce performance. 

Although automatic conversion of 
uniprocessor programs to multiprocessor 
programs is desirable, rewriting programs 
for a multiprocessor model is currently 
more practical. In addition, knowledge 
gained by writing for such a model may 
provide valuable information for con¬ 
struction of automatic conversion 
programs. 

To program a multiprocessor using a 
uniprocessor-style language, some primi¬ 
tive constructs for data exchange and syn¬ 
chronization must be added. For a 
shared-memory system, data exchange is 
accomplished implicitly, since (ideally) 
each processor has access to all data from 
the other processors. Synchronization 
primitives for shared-memory systems are 
generally simple; for instance, they might 
allow one processor to wait for another 
processor to reach a certain point in its 
program. For local-memory systems, data 
exchange is accomplished explicitly, 
usually by allowing processors to exchange 
“messages” containing data. Such a mes¬ 
sage primitive can be used to provide syn¬ 
chronization as well. For example, a 
processor can “know” that another 
processor has reached a certain point by 
waiting for a message from it. The appro¬ 
priate primitives for both shared- and 
local-memory systems are still the subject 
of much debate. 


The Armstrong system 

Armstrong is a hardware-software sys¬ 
tem that will allow us to address some of 
the problems discussed above. The pri¬ 
mary goal was to construct a useful, con¬ 
trollable, research-oriented parallel¬ 
processing system with approximately 100 
processors. Since known techniques would 
probably not work for a shared-memory 
system of this size, we designed the system 
around the local-memory model. 

The Armstrong hardware consists of P 
identical processing nodes (currently 68) 
connected by a high-speed point-to-point 
network. The processor hardware is not 
specialized to any set of applications; it is 
based on the Motorola 68010 microproces¬ 
sor, with the National Semiconductor 
32081 for hardware floating-point sup¬ 
port. Although similar to hardware used 
in other systems, it has several features that 
make it unique. First, the I/O network is 
reconfigurable, which allows researchers 
to experiment with different topologies, 
including hypercubes, trees, and meshes. 
In addition, the hardware supports a very 
high data rate relative to processor speed 
(40 megabits per second for about 0.5 
MIPS) in an attempt to lessen the impact 
of I/O operations on the performance of 
parallel applications. Finally, the hard¬ 
ware supports virtual memory, which is 
useful for the debugging of applications 
and could be used to simulate shared mem¬ 
ory in some circumstances. 

Each node in the system runs a copy of 
the Armstrong operating system. The 
main purpose of the operating system is to 
make the hardware easier to program. On 
a uniprocessor system, an application 
generally consists of a process with its own 
private address space. On Armstrong, an 
application consists of several processes, 
each executing in its own private address 
space. The operating system provides 
mechanisms for these processes to 
exchange data by sending messages. How¬ 
ever, many aspects of the hardware are 
hidden from the programmer. For 
instance, all communication is location 
independent. Processes have symbolic 
names, and messages are sent to and 
received from symbolic names without 
regard to the physical placement of the 
processes. Message routing is determined 
automatically and dynamically by the 
operating system from its observation of 
the current network configuration. Phys¬ 
ical node numbers are required only to 
start a process. In addition, the message¬ 
passing services provide idealized func¬ 


tionality, including arbitrary-length mes¬ 
sages, complete error checking and 
recovery, and flow control. 

The hardware, operating system, and 
applications were designed and con¬ 
structed in the Laboratory for Engineer¬ 
ing Man/Machine Systems, Division of 
Engineering, at Brown University. This 
allowed detailed control over the system 
features. Hardware design began in Janu¬ 
ary 1984 and the final version was com¬ 
pleted in November 1985. System software 
design and construction began in January 
1985 and was completed in September 
1987. The first application was demon¬ 
strated in November 1985, and application 
development continues to this date. 

This article will describe briefly the 
Armstrong hardware and then discuss, in 
depth, the operating system software, 
applications software, and performance of 
the system on a real application. 

Hardware 

Although the principles explored in this 
article are applicable to many different 
multiprocessor systems, a brief summary 
of the hardware functionality will help 
support the software description. A more 
thorough description of the hardware is 
available. 6 The Armstrong system is a 
loosely coupled general-purpose parallel¬ 
processing system made up of many 
(about 100) identical processing nodes. 
Each node contains a CPU, memory, and 
I/O hardware. The nodes are connected by 
a high-speed point-to-point network. Fig¬ 
ure 1 shows a block diagram of a single 
node. 

The processing node is based on the 
Motorola 68010 microprocessor operating 
at 10 megahertz with no memory wait 
states. The 68010 has 32-bit registers, 
16-bit data paths, and 24-bit addressing. 
At a 10-megahertz clock speed, the mem¬ 
ory cycle time is 400 nanoseconds, and the 
speed is generally rated at about 0.5 MIPS. 
Floating-point support is provided by a 
National Semiconductor 32081 coproces¬ 
sor chip. It is interfaced as a peripheral 
device, not as a coprocessor, because the 
68010 does not support a coprocessor 
interface. Although computations are not 
as fast as they would be with a true 
coprocessor, they are much faster than 
with software-based floating point. Table 
1 shows floating-point operation execu¬ 
tion times, measured for compiled C- 
language code. 

Each node contains 512 kilobytes of 
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Figure 1. Armstrong node block diagram. 


Table 1. Floating-point-operation exe¬ 
cution times (double precision, all times 
in microseconds). 


Operation 

With 

32081 

Without 

32081 

Add/subtract 

48.8 

146.5 

Multiply 

48.1 

167.8 

Divide 

52.5 

374.6 


dynamic RAM, with a 150-nanosecond 
access time. The dynamic RAM is 
refreshed by software. This introduces a 
small performance penalty (about one per¬ 
cent) in exchange for a significant decrease 
in hardware complexity. In addition, each 
node has a small amount (16 kilobytes) of 
slow (250-nanosecond access time) 
EPROM for self-test and bootstrap code, 
and a simple timer chip (Motorola 6840) 
for use by the system software. 


To protect the operating system from 
user-code errors, each node contains a 
memory management unit, or MMU. The 
68010 supports protection by having two 
execution modes: supervisor mode, used 
by the operating system; and user mode, 
used by application programs. These 
modes protect the operating system in two 
ways. First, although all instructions can 
be executed when in supervisor mode, 
instructions that can affect other programs 
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cannot be executed in user mode. Second, 
whenever the CPU performs a memory 
access, it signals the MMU and indicates 
the current mode. In supervisor mode, the 
MMU maps virtual addresses directly to 
real addresses with no translation. In user 
mode, the MMU maps the entire 24-bit 
virtual-address space to a 24-bit real- 
address space, using a page size of 4096 
bytes. 

The MMU hardware can support full 
demand paging, although the software to 
support this has not been implemented. 
Rather than incorporating a commercially 
available MMU chip, the MMU is custom 
built out of fast (50-nanosecond) static 
RAM chips. This is because, at the time of 
Armstrong’s design, commercial MMUs 
were too slow to allow the 68010 to access 
main memory at full speed. The custom 
approach involves a drawback in that the 
system software must reload the static 
RAMs whenever the processing context is 
switched. 

Each node has eight serial I/O ports, 
each connecting directly to exactly one 
port on one other node. The links are two 
bits wide, bidirectional, and half duplex, 
and operate at a burst rate of 20 mega¬ 
hertz, or 40 megabits per second. The I/O 
hardware directly supports packet 
switching 7 ; the software specifies a port 
number, a packet address, and a packet 
length, and the DMA hardware transfers 
the packet from the local memory directly 
to the memory of the neighboring node. 
The system software is responsible for for¬ 
warding packets between nonadjacent 
nodes and for any error checking and 
recovery. 

The Armstrong hardware is constructed 
on a Multibus I backplane, with one node 
per board. The backplane provides power 
and mechanical support only, not commu¬ 
nication. The I/O ports are brought out to 
the edge of the boards with 10-pin connec¬ 
tors. All cabling is done manually, using 
“patch-cords” made from thin cable with 
connectors at each end. This allows a 
researcher to select any desired communi¬ 
cations topology, within the eight-ports- 
per-node constraint. The I/O signals are 
driven by differential drivers; thus the 
cabling can be relatively long (around 100 
feet). Figure 2 is a photograph of a single 
Armstrong node. The nodes were con¬ 
structed using the Augat Unilayer II pro¬ 
cess, 8 a quick-turnaround prototyping 
system. 

The on-board bus of each node is avail¬ 
able at a 60-pin edge connector. This ena¬ 
bles the connection of various specialized 



Figure 2. A single Armstrong node. 


peripheral devices to any node. 
Peripherals constructed so far include a 
general Multibus I interface, which allows 
commercial peripherals to be attached; an 
analog-to-digital converter for sampling 
speech signals; and a 512 x 480-pixel, 
16-plane color graphics display. The com¬ 
plete Armstrong system is distributed to a 
number of physical locations in our 
laboratory, including a robot-control sys¬ 
tem, a computer vision system, two 
speech-processing systems, and several 
graphics stations. In addition, a large rack 
containing about 40 nodes is used for 
highly parallel application experiments 
(see Figure 3). 


System software 

The software running on the Armstrong 
system consists of the application program 
and the operating system. The application 
program is the code written by a user to 
perform a particular task, using the ser¬ 
vices provided by the operating system. 
The operating system consists of the server 
processes, which implement high-level 
functions, and the kernel, which interfaces 
with the hardware. Figure 4 is a block dia¬ 
gram of the operating system. We will 
describe the interface between the pro¬ 
grammer and the operating system, as well 
as the operating system itself. 



Figure 3. The Armstrong rack contains 
about 40 nodes. 


June 1988 


41 
















Application layer 

Node-manager 
and other servers 

Presentation layer 

Scheduler 

Session/transport 

layer 

Network layer 

Interrupt 

service 

routines 

Data-link layer 

Hardware 


Server 

processes 


Kernel 


Operating 

system 


Figure 4. Armstrong operating-system block diagram. 


Programmer’s interface. The Arm¬ 
strong operating system supports mul¬ 
titasking on each Armstrong node. 
Processes can communicate with each 
other using interprocess communication 
(IPC) services provided by the operating 
system. In general, the system looks like a 
uniprocessor system with many processes. 
As far as the programmer is concerned, 
interaction between two processes is the 
same whether they are on the same node or 
not. 

Programs for the Armstrong system are 
generally written in C, although assembly- 
language programming is also supported. 
Additional C functions have been 
provided for performing IPC and other 
activities not available in standard C. We 
will briefly describe some of these addi¬ 
tional functions using sample C calls. Note 
that all Armstrong functions return an 
integer indicating whether the operation 
succeeded or failed. To make the descrip¬ 
tions concise, return-code checking has 
been left out of the examples. 

Most communication in Armstrong is 
by virtual circuits. 1 Virtual circuits offer 
very reliable communication. For exam¬ 
ple, they guarantee that any data sent by 
one process to another will (eventually) be 
received at the destination unless the 
source or destination node crashes. In 
addition, they guarantee that consecutive 
messages sent from a source to the same 
destination will arrive in the order sent. 
Virtual circuits also provide flow control 


so that a fast sender cannot overwhelm a 
slow receiver. Communication is asyn¬ 
chronous in that the sender can continue 
executing after sending a message without 
waiting for the message to be received, as 
long as buffering space is available. If 
buffering space runs out, the sender will 
have to wait until space is available. 

To provide these characteristics, a vir¬ 
tual circuit requires that a connection be 
established between two processes before 
they can communicate. To set up a virtual 
circuit connection between two processes, 
one process must assign itself a symbolic 
name using ns_bind and then wait for a 
connection request with ipc_accept: 

ns_bind(“procl”); 

ipc_accept(&cid); 

Here, the first process assigns itself the 
symbolic name “prod” and waits for a 
connection request. When the connection 
request is accepted, ipc_accept returns the 
connection ID cid, which is an integer used 
to refer to the connection in subsequent 
function calls (a connection ID is analo¬ 
gous to the Unix file descriptor). 

Once the first process has called 
ipc_accept, the second process must call 
ipc_connect to establish the connection: 

ipc_connect(“procl”, &cid); 

Here, the second process connects to the 
first process (“prod”) and receives its 


own connection ID to refer to the connec¬ 
tion in the future. In general, the two con¬ 
nection IDs for the same connection will 
not be equal. 

Once the connection is initialized, either 
process can send data by calling ipc_send: 

ipc_send(cid, INT(5), 

STRING(“Hello, world”), 
STRUCT(data), EOA); 

In this example, the process wants to send 
the integer 5, the string “Hello, world”, 
and the structure named data on the con¬ 
nection identified by the connection ID 
cid. The special argument EOA marks the 
end of the data list. INT, STRING, and 
STRUCT are C macros that expand into 
two or three arguments to ipc_send. The 
first argument describes the data’s type, 
while the second contains either the data’s 
value (if it is short enough) or the data’s 
address. For data whose size cannot be 
determined from the type (such as struc¬ 
tures), a third argument describes the 
data’s length in bytes. The recipient 
receives the data by calling ipc_recv: 

ipc_recv(cid, RINT(i), 

RSTRING(str, sizeof(str)), 
RSTRUCT(data), EOA); 

Here, the other process receives the integer 
into the variable i, the string into the array 
str, and the structure into the variable 
data. Other data types supported by 
ipc_send and ipc_recv include single 
characters, floating-point numbers, and 
unstructured byte strings. Additional IPC 
functions allow a process to close a con¬ 
nection, discover the name of the process 
on the far end of a connection, and wait 
for activity on more than one connection 

Armstrong provides another form of 
communication known as datagrams. 
Datagrams make it possible to send one 
message to one or more destination pro¬ 
cesses without establishing a connection. 
The message length is limited to one packet 
(currently 1,024 bytes) and delivery is not 
guaranteed. No acknowledgment of deliv¬ 
ery is provided even if it succeeds, and mes¬ 
sages will not necessarily arrive in the order 
sent. Datagrams have two main advan¬ 
tages over virtual circuits: First, they are 
very efficient, since little error checking is 
done. This is appropriate for applications 
where the loss of some messages is tolera¬ 
ble. Second, they allow multicasting, 
where a message is sent to more than one 
process. Since datagrams are rarely used 
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by application programs, we will not dis¬ 
cuss them in detail. 

Processes can also perform various con¬ 
trol operations. For instance, a new pro¬ 
cess can be created on any node by calling 

pm_start_proc 

(“file”, pri, node, “stdio”, args); 

where “file” is the file containing the new 
process’s code, pri is the scheduling pri¬ 
ority for the new process, node is the num¬ 
ber of the node on which the new process 
should be created,“ stdio ” is the name of 
the terminal the new process should use for 
its standard input and output, and args are 
the arguments to be passed to the new pro¬ 
cess. Other functions allow a process to 
terminate another process, map part of its 
address space to a physical device, and 
load and manipulate interrupt service rou¬ 
tines. We will discuss these operating- 
system services later. 

Server processes. Server processes exe¬ 
cute under control of the kernel process 
scheduler, just as application processes do. 
They serve as an interface between appli¬ 
cation processes and the kernel services. 

Node-manager. In uniprocessor operat¬ 
ing systems, application processes requir¬ 
ing operating-system services can request 
them by standard subroutine calls. Unfor¬ 
tunately, on a local-memory multiproces¬ 
sor system, applications can make 
subroutine calls only to the operating sys¬ 
tem on their own node. There are several 
ways to address this problem. For exam¬ 
ple, one could enable the operating system 
to communicate with applications on any 
node via the standard message-passing sys¬ 
tem. 9 The approach we have taken is to 
have on each node a special process that 
performs control operations for applica¬ 
tion processes. On the Armstrong system, 
this process is called the node-manager. 

The node-manager provides an inter¬ 
face between application processes and the 
local kernel. It accepts requests through 
the standard interprocess communication 
services, and calls subroutines in the ker¬ 
nel to carry out the requests. In most ways 
the node-manager is just like an applica¬ 
tion process in that it runs under control 
of the kernel process scheduler. The only 
real difference is that no other process is 
allowed to call most of the kernel services 
directly. (The services that any process can 
call are very simple, such as “change my 
scheduling priority.”) The functions 
provided by the node-manager include 


process management, a distributed name 
database, memory management, excep¬ 
tion handling, and interrupt-service- 
routine loading. 

Process management involves creating 
and deleting processes. Upon request, the 
node-manager will allocate memory for a 
new process, assign it a process number, 
load the code and data from the specified 
file, and initialize the new process’s page 
table. Once the process has been success¬ 
fully loaded, the node-manager calls a ker¬ 
nel service to add the process to the 
scheduler’s table. When the process exits, 
the kernel notifies the node-manager, 
which reclaims the process’s memory 
space. The node-manager can also force a 
process to exit if requested. 

To make loading of a process and its 
page tables easier, the node-manager’s 
page tables are initialized to map the entire 
real-memory space of the node as a read- 
write part of the node-manager’s address 
space. Ideally, program code and data are 
read from a disk device. However, since no 
disk is attached to the system at present, 
file service is provided over Ethernet by 
our main host machines (currently two 
Sun-3/260s). 

Within the kernel, all processes are iden¬ 
tified by a 64-bit number called a global 
process ID (GPID), which is analogous to 
the Unix process ID. A GPID consists of 
a 32-bit node number and a 32-bit process 
number. Thus, each node can manage its 
process numbers independently while still 
assigning each process an identifier that is 
unique among the entire set of intercon¬ 
nected Armstrong nodes. While the GPID 
is convenient for the kernel, applications 
programmers prefer to use symbolic 
names for processes. Thus, the node¬ 
manager provides a distributed name data¬ 
base to map between symbolic names and 
GPIDs. Processes register their symbolic 
name by calling ns_bind (discussed 
earlier), and system functions automati¬ 
cally convert from symbolic name to 
GPID when necessary. 

To understand how the distributed data¬ 
base works, consider the following exam¬ 
ple: A process created on node 42 wishes 
to use the symbolic name “printer- 
server.” Thus the process calls ns_bind, 
which sends a message to the node¬ 
manager on node 42 (NM-42) asking that 
the name be associated with this process. 
NM-42 broadcasts a lookup request to all 
other node-managers, asking whether any 
process with this name currently exists. If 
no positive replies occur, NM-42 enters the 
name in an internal table. When a process 


on node 54 wants to establish a connection 
to the “printer-server” process, it calls 
ipc_connect. The ipc_connect function 
sends a message to the node-manager on 
node 54 (NM-54) requesting the GPID 
associated with that symbolic name. 
NM-54 broadcasts a lookup request, 
NM-42 replies with the GPID for “printer- 
server, ’ ’ and NM-54 returns the informa¬ 
tion to ipc_connect. Then ipc_connect 
completes the connection by calling a 
lower level kernel service and passing it the 
GPID. 

The node-manager also provides 
general memory-management functions, 
but only for local processes (those on its 
node). Local processes can request that 
additional data space be allocated (usually 
for their internal memory-allocation rou¬ 
tines). They can also request that portions 
of their address space be mapped to por¬ 
tions of the real-address space on the 
peripheral connector (this is done through 
page-table manipulation). For example, 
the color-graphics display peripheral men¬ 
tioned earlier is accessed by mapping part 
of the user-process’s space into the display 
frame buffer. The display is then accessed 
as if it were an array in the process’s 
memory. 

In addition, the node-manager handles 
all processor exceptions (such as “illegal 
instruction”) generated by other pro¬ 
cesses. When an exception occurs, the ker¬ 
nel, acting on behalf of the faulting 
process, sends a message to the node¬ 
manager including the exception data 
from the user’s stack. In most cases the 
error is uncorrectable and the process is 
terminated with an error message. How¬ 
ever, if the exception was generated by the 
memory management unit and indicates 
that the user stack has overflowed, the 
node-manager extends the stack and sends 
a “continue” message to the faulting 
process. 

Device servers. Many operating systems 
include the device-controlling code in the 
kernel. The disadvantage of this approach 
is that either a different copy of the kernel 
must exist for every device configuration 
in use, or the kernel must include support 
for every possible device. To avoid this 
problem, the Armstrong system uses 
server processes to control devices. 

Device servers are the interface between 
devices and application processes, just as 
the node-manager is the interface between 
the kernel and application processes. They 
communicate with processes via the stan¬ 
dard interprocess communication services 
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and communicate with devices by map¬ 
ping parts of their address space to the 
device addresses (by request to the node¬ 
manager). The only shortcoming of this 
strategy is with the handling of interrupts. 
When a device interrupt occurs, the device 
must be serviced immediately, since the 
pending interrupt will prevent normal pro¬ 
cess scheduling. 

To address these needs, the Armstrong 
operating system allows interrupt service 
routines, or ISRs, to be loaded dynami¬ 
cally into the kernel. To load an ISR, the 
device server sends a request to the node¬ 
manager, which will allocate up to one 
page (4 kilobytes) of memory and load the 
ISR from a file. (The one-page limit is 
imposed to make memory management 
easier, since the ISRs run in supervisor 
mode and thus do not use the address 
translation hardware.) The device server’s 
page table is modified to give the server 
access to the ISR’s address space, thus 
allowing the server and the ISR to share 
data structures (for example, a terminal- 
device server and its ISR might share 
queues for characters being sent and 
received). Finally, the node-manager noti¬ 
fies the kernel that the ISR should be 
invoked whenever an interrupt from the 
specified device occurs. 

Once the ISR initialization has been 
completed, a device interrupt will jump 
immediately to the ISR code. The ISR 
takes the appropriate action, depending on 
the device’s requirements, and may 
modify local variables or variables that it 
shares with the device server. If the device 
server is waiting for some device action to 
be completed, the ISR may awaken the 
server process. 

The Armstrong system currently 
includes a number of device servers; the 
most important is the Ethernet server. The 
current Armstrong system includes a com¬ 
mercial Ethernet board, which provides 
complete support for TCP/IP (Transmis¬ 
sion Control Protocol/Internet Protocol 10 ) 
with an on-board protocol processor. The 
Ethernet server’s function is to allow user 
processes to open TCP streams and to 
multiplex the data between the user pro¬ 
cesses and the Ethernet board software. 
The Ethernet is used to boot Armstrong 
nodes, provide file service for Armstrong 
nodes, and provide network connections 
between Armstrong and non-Armstrong 
software. 

Other device servers are added to the 
system as needed. At present these include 
servers to handle serial communications 
ports (terminals); servers for color 


graphics displays; servers for controlling 
robot systems; a server for a video frame 
buffer, which acquires still images from a 
video camera and transfers them to other 
nodes; and a server for the analog-to- 
digital converter, which can sample and 
transfer speech signals in real time at up to 
12 kilohertz. 

Other servers. To run programs, users 
first establish a TCP connection to a login 
server on Armstrong using the Unix rlogin 
command from one of the host machines. 
Each login session requires one login 
server and provides a virtual terminal for 
user input and output. Each login server 
is initially connected to one user process— 
a command interpreter (or “shell”). This 
allows users to start any program on any 
node. Once started, each program estab¬ 
lishes a connection to the login server that 
initiated it, thus enabling it to print output 
on and receive input from the user’s real 
terminal. As a result, multiple users can be 
logged into Armstrong and working simul¬ 
taneously. 

Other server processes include the sys¬ 
tem console, which receives system error 
messages (such as hardware transmission 
errors) and displays them on a dedicated 
ASCII terminal; and the boot server, 
which downloads the kernel and node¬ 
manager to newly booted nodes. 

Kernel. The kernel provides an interface 
between the hardware and the high-level 
functions provided by the node-manager. 
Kernel services are divided into two 
groups: those related to process manage¬ 
ment and those related to interprocess 
communications. 

Process management. Process manage¬ 
ment services are divided into two parts: 
the scheduler and the interrupt service rou¬ 
tines. The scheduler is priority driven in 
that the highest priority process always 
runs if it is ready (that is, if it is not wait¬ 
ing for some event). If more than one pro¬ 
cess has the highest priority, they are 
time-shared. If a low-priority process is 
running and a high-priority process 
becomes ready, the high-priority process 
takes precedence. 

These characteristics enable us to run 
real-time programs, such as those involved 
in data acquisition, by giving them the 
highest priority on their node(s). However, 
care must be taken with such programs, 
since they will monopolize the CPU if they 
do not pause to wait for events. Since the 
node-manager handles high-level process 


management functions, the only process 
management services provided by the ker¬ 
nel are those that add a process to the 
scheduler’s tables, set the scheduling pri¬ 
ority of a process, or delete a process from 
the scheduler’s table. 

The interrupt service routines, or ISRs, 
handle interrupts from various on-board 
and off-board devices. On-board device 
interrupts are handled directly by the 
appropriate section of the kernel and 
include scheduling-clock interrupts (han¬ 
dled by the scheduler) and I/O interrupts 
(handled by the communications services). 
As described earlier, off-board interrupts 
are handled by ISRs loaded by the node¬ 
manager. The kernel provides services to 
route interrupts from specific off-board 
devices directly to these ISRs. 

Communications. The Armstrong ker¬ 
nel provides a very sophisticated commu¬ 
nications system, which we will describe by 
comparing it with the Open Systems Inter¬ 
connect reference model. 7 The top layer 
of the OSI model is the application layer. 
In the Armstrong system, this includes the 
application programs and the server pro¬ 
cesses. This layer does not provide any 
communication services; it only makes use 
of them. 

In general, applications programmers 
prefer to think of the data they send as a 
sequence of abstract data types such as 
integers, strings, and structures. This rep¬ 
resentation is supported at the user inter¬ 
face level in Armstrong by ipc_send and 
ipc_recv. However, the lower level com¬ 
munication layers of Armstrong require 
that data be presented as a sequence of 
fixed-length blocks (packets). The func¬ 
tion of the next layer, the presentation 
layer, is to convert between these two 
representations. ipc_send scans the list of 
data items, converting them into a packet 
sequence. As each data item is packaged, 
it is prefixed by a code indicating its type 
and, if necessary, its length. When the data 
arrives at the receiving node’s presentation 
layer, ipc_recv unpackages the data and 
deposits it in locations specified by the 
receiving application process. As the data 
is unpackaged, the presentation layer veri¬ 
fies that the received data types match the 
types expected by the receiving appli¬ 
cation. 

The next layer of communications soft¬ 
ware is the session/transport layer, which 
includes the functions of both the OSI ses¬ 
sion layer and the OSI transport layer. 
This layer is responsible for establishing 
connections between processes and for the 
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reliable delivery of data. Since the data¬ 
gram protocol requires neither connec¬ 
tions nor reliable delivery, this layer 
essentially passes datagrams unchanged. 

In contrast, the virtual-circuit protocol 
requires a great deal of support from the 
session/transport layer. The virtual-circuit 
protocol in Armstrong is modeled closely 
on TCP, although it is considerably sim¬ 
pler because it omits many features that 
are unnecessary in a homogeneous envi¬ 
ronment like the Armstrong system. 

When the initialization of a virtual- 
circuit connection is requested (by 
ipc_connect), the session/transport layer 
sends the destination node a request for 
connection. There, the remote ses¬ 
sion/transport layer initializes its side of 
the connection (assuming the local process 
has called ipc_accept) and replies with an 
acknowledgment. Connection informa¬ 
tion is maintained only at the source and 
destination nodes, and no intermediate 
node is aware of the connection. When 
data are exchanged between the two appli¬ 
cation processes, the session/transport 
layer assigns sequence numbers to packets 
to help maintain their ordering, and uses 
acknowledgment packets to confirm their 
receipt. If no acknowledgment is received 
by the sending session/transport layer 
within a certain time (currently one sec¬ 
ond), the packet in question is retransmit¬ 
ted. Duplicate packets (caused by lost 
acknowledgment packets) are automati¬ 
cally discarded by the receiving ses¬ 
sion/transport layer. 

The next layer in the communications 
system is the network layer. This layer 
accepts single packets from the ses¬ 
sion/transport layer and attempts to 
deliver them to the destination node. The 
service this layer provides is essentially the 
same as the datagram service. Since the 
Armstrong system allows the network to 
be dynamically reconfigured, the biggest 
task for this layer is to determine the cor¬ 
rect routing of packets from the source to 
the destination. 

When a packet is received from the ses¬ 
sion/transport layer, the network layer 
first checks to see if it is intended for the 
current node. If it is, the packet is passed 
back up to the session/transport layer for 
delivery to the appropriate process. If not, 
the network layer consults a routing table 
(maintained by the network layer) to deter¬ 
mine the communications port to use for 
the “best” route to the desired destination 
node. The packet is then put on the outgo¬ 
ing packet queue for that port. Thus, most 
of the network layer is concerned with 



best_dist = table [packet, source], dist (°° if no route available) 
best_port = table [packet, source] .port 
best_seq = table [packet. source]. seq 
if packet.dist < besLdist OR (packet.dist = best_dist AND 
packet.port = best_port AND packet.seq best_seq) 
table [packet. source]. dist = packet. dist 
tablefpacket.source] .port = packet.port 
table [packet. source]. seq = packet. seq 
table [packet, source], status = AVAILABLE 
packet.dist = packet.dist + 1 
for p = 0 to 7 
if /?=/= packet.port 
send packet on port p 

else 

discard packet 


Figure 5. The actions taken when a routing packet is received. 


maintaining this routing table. 

The best route from source to destina¬ 
tion is determined by the criteria for 
“best.” Originally, the Armstrong net¬ 
work layer tried to use the route that took 
the least amount of time from source to 
destination. Unfortunately, the routes 
selected were sometimes longer than neces¬ 
sary. For example, the quickest route 
might be three hops (two intermediate 
nodes), even though a two-hop route 
existed. This resulted from the basic design 
of the communications hardware. Since 
only one port can be active on a node at a 
time, packets were sometimes delayed long 
enough to make a three-hop route appear 
faster than a two-hop route. 

We decided that minimum-hop routes 
were more appropriate for the production 
system, since they would most likely be 
optimal under heavy loads and would also 
be more predictable. Thus, the current net¬ 
work layer dynamically determines the 
shortest (minimum-hop) route for packets 
by using the following algorithm: Each 
node broadcasts (sends on every port) a 
special routing packet every t rb seconds. 
When adjacent nodes receive the packet, 
they check to see whether they have 
already received a copy of this packet by 
looking at its sequence number (set by the 
originating node). If its sequence number 
matches that of a routing packet they have 
already received from the originating 
node, the packet is discarded. If not, it is 
transmitted on every port except the one 


on which it arrived. 

Since it is impossible to keep a record of 
the sequence number of every routing 
packet ever received from every node, each 
node records only the sequence number of 
the last routing packet received from every 
node. A new routing packet is assumed to 
be a duplicate if its sequence number 
matches that of the last routing packet 
received from the originating node. 
Although this method saves storage space, 
it requires that all copies of a routing 
packet be discarded from the system 
before the next routing packet is broad¬ 
cast. This requirement is thus a factor in 
the choice of t rb . 

The pseudocode in Figure 5 describes 
the actions taken when a routing packet is 
received. The description uses the follow¬ 
ing variables: 

table—the routing table, which is an 
array of structures, indexed by destina¬ 
tion node. Each entry contains routing 
information for that destination node, 
including 

seq—the sequence number in the last 
packet received from the node 
port—the port on which the last 
packet was received (and thus the out¬ 
going port to use for the best route to 
this destination) 

dist—the distance (in links) to the 
node 

status—the status of the route: 
“available,” indicating the route can 
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be used; “unconfirmed,” indicating 
the route may no longer be available; 
or “none,” indicating that no route 
is available 

packet—a structure representing the 
routing packet just received; the mem¬ 
bers include 

source—the source node of the 
packet 

seq—the sequence number of the 
packet, which is assigned by the 
source node and incremented by one 
after each broadcast 
port—the number of the port on 
which the packet was received 
dist—the number of links the packet 
has so far traversed (incremented 
when a packet is forwarded) 

Essentially, each node looks for routing 
packets coming in from all other nodes. 
When a node sees one that arrived with 
fewer hops than the previous best route 
required (initially infinitely long), it 
chooses this new route. The periodic 
broadcast of routing packets ensures that 
the routing table is kept up to date. This 
algorithm finds one of the shortest routes 
from AtoB and will keep using the same 
route as long as it continues to receive rout¬ 
ing packets via that route. 

To detect routes that have become unus¬ 
able, a kernel service that examines the sta¬ 
tus of each routing-table entry is called 
every t K seconds. If the status is “avail¬ 
able,” the status is set to “unconfirmed,” 
meaning the route is still assumed to be 
usable but has not been recently confirmed 
by receipt of a routing packet. Usually a 
routing packet will arrive before another 
t rc seconds passes, and its arrival returns 
the status to ‘ ‘available. ” 1 f the kernel ser¬ 
vice finds that the status is already 
“unconfirmed,” the status is set to 
“none” and the distance is set to 00 , 
indicating that no route is available. A new 
route will then be found, if one exists. At 
present, t r , is set to 2 t rb + 1, which allows 
a route to remain available unless two con¬ 
secutive routing packets are lost. 

As discussed earlier, one factor 
influencing the selection of t rb is the 
requirement that all copies of a node’s 
routing packet drain from the system 
before the broadcast of its next routing 
packet. Since the Armstrong I/O hard¬ 
ware and software are very fast, packets 
drain from the system in well under a 
second. 

Two other important factors influence 
the selection of t rb . If t rb is small, the net¬ 


work will adapt quickly to changes in 
topology. However, this may result in a 
large amount of overhead. For example, 
if t rb = 1 and the system contains 100 
nodes, there will be a load of 100 packets 
per second on the network even when there 
is no application data traffic. On the other 
hand, if t rb is large, too much time may be 
required to adapt to topology changes. At 
present, t rb is set to 20 seconds. An 
interesting variation, which we have not 
tried, would be to have two types of rout¬ 
ing packets: one just like the present 
packets and a second type that would 
travel only a few hops from the source 
before decaying. Thus, local nodes would 
be kept more up to date than would distant 
nodes. 

We mentioned earlier that the datagram 
protocol allows multicasting, where a 
packet is sent to more than one destination 
process. Support for this function is 
provided in the network layer. If a packet 
received by the network layer has a GPID 
node number of negative one (binary all 
ones), this indicates that it should be mul¬ 
ticast to all processes on all nodes having 
the process number indicated in the GPID. 
At present, this function is useful only for 
the node-managers, since application pro¬ 
grams cannot guarantee that their pro¬ 
cesses will be assigned the same process 
number on different nodes. However, all 
node-managers have a process number of 
one. 

The routing table already discussed can 
support an algorithm called reverse path 
forwarding 1 to handle routing for multi¬ 
cast packets. At the source node a multi¬ 
cast packet is sent on all outgoing ports. 
Then, when the packet is received on other 
nodes, the algorithm examines the 
packet’s source-node number and deter¬ 
mines which port would have been used to 
send a packet from the receiving node to 
the source node. If it is the same as the port 
on which the multicast packet arrived, the 
packet is delivered to the appropriate pro¬ 
cess on the receiving node (if it exists) and 
also retransmitted on every port except the 
one on which it arrived. If it is not the same 
port, it is assumed to be a duplicate and is 
discarded. 

The lowest software layer of the com¬ 
munication services is called the data-link 
layer. Its purpose is to take the services 
provided by the raw hardware and trans¬ 
form them into an error-free packet- 
transmission service. The network layer 
passes a packet to the data-link layer along 
with the number of the port on which it 
should be sent. The data-link layer com¬ 


putes a software checksum on the packet 
header, which includes the source and des¬ 
tination addresses, and appends it to the 
header. A software checksum is also com¬ 
puted on the data portion of the packet 
and appended to the data. The packet is 
put in the outgoing queue for that port and 
transmitted when it reaches the head of the 
queue. 

When a packet is received on the far end 
of the communication link, the data-link 
layer computes the checksum of the header 
it received and compares it with the 
expected checksum at the end of the 
header. If they do not match, the packet 
is discarded. If the header checksums 
match and the packet is addressed to the 
receiving node, the packet data checksum 
is also calculated and checked. Again, the 
packet is discarded if the data checksum 
does not match. For the sake of efficiency, 
the data checksum is only checked at the 
final destination. Checking only the 
header at intermediate nodes is quicker 
and there is no danger of a data error 
affecting intermediate nodes, since inter¬ 
mediate nodes do not examine the data. 
The data-link layer does not attempt to 
recover from transmission errors, since 
this is the responsibility of the ses¬ 
sion/transport layer. 

Performance 

Below we present data relating to the 
I/O performance of the Armstrong sys¬ 
tem. Although these numbers are not very 
meaningful by themselves, they form a 
basis for comparing Armstrong with other 
parallel processing systems and for 
estimating the performance of applica¬ 
tions before they are written. 

Although the hardware achieves a burst 
transfer rate of 5 megabytes per second, 
the actual data rate between user processes 
is considerably slower. The time required 
for an I/O operation can be accurately 
modeled as a constant overhead plus a 
time that varies linearly with the number 
of bytes. Times were measured for com¬ 
munications between adjacent nodes that 
were otherwise idle. Measurements were 
taken by having a process send a message 
to a second process and then having the 
second process immediately send the same 
message back. The elapsed time observed 
by the first process was divided by two to 
compute the one-way message time. Thus, 
the time reflects the actual delay from the 
time ipc_send was called until ipc_recv 
returned. Table 2 summarizes the timings. 
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Note that the effective transfer rates for 
large messages are 280 kilobytes per sec¬ 
ond for virtual circuits and 400 kilobytes 
per second for datagrams. Measurements 
were also taken of the time required to 
initialize a virtual-circuit connection 
(including the time to look up the symbolic 
name and initialize data structures at both 
nodes) and the time required to close a 
connection. Table 3 summarizes these 
times. 

As expected, the datagram protocol is 
the most efficient, since it involves the least 
protocol processing. In contrast, the 
virtual-circuit protocol has about 
50 percent more fixed overhead, although 
the actual time is still small. For large mes¬ 
sages, the virtual-circuit protocol achieves 
about 70 percent of the end-to-end data 
rate of the datagram protocol. 


Application 

We will now provide a detailed descrip¬ 
tion and analysis of an application devel¬ 
oped for use on the Armstrong system. We 
have chosen to describe a single applica¬ 
tion in detail rather than provide limited 
information about a number of applica¬ 
tions. The application computes the two- 
dimensional discrete Fourier transform of 
an image. The two-dimensional DFT has 
numerous applications in image analysis 
and image coding and has characteristics 
typical of large scientific matrix/vector 
calculations. Researchers generally con¬ 
sider it a difficult problem for local- 
memory multiprocessors to solve effi¬ 
ciently. 

Input to the application consists of an 
Ax Aarray of eight-bit unsigned-integer 
intensity values. A must be a power of 2 
and may not be greater than 128 (because 
of memory limitations). There are a num¬ 
ber of ways to implement a two- 
dimensional DFT." In the method used 
here, a one-dimensional A-point DFT is 
performed on each row of the image, and 
then a one-dimensional A-point DFT is 
performed on each column of that result. 
This suggests that a parallelism of up to A 
is possible, since all the row DFTs can be 
done in parallel, as can all the column 
DFTs. 

The application is structured as one 
master process and P slave processes. Fig¬ 
ure 6 shows the communication structure 
for P= 8. Each slave must communicate 
with every other slave and the master. Note 
that this illustrates the logical communica¬ 
tion structure of the application, not the 


physical network topology. The master 
process acquires the image (from either the 
digitizing camera or a disk file) and distrib¬ 
utes it to the slave processes, with each 
slave receiving N/P rows of image data. 
(For simplicity, P must be a power of 2, so 
that A/Pis integral.) Each slave then com¬ 
putes N/P one-dimensional DFTs, using 
a radix-2 fast Fourier transform algo¬ 
rithm. Next, the distributed matrix of 
intermediate results is transposed by hav¬ 
ing each slave exchange data with every 
other slave so that each gets N/P columns 
of the intermediate result. Once the trans¬ 
pose is completed, each slave computes 
another N/P one-dimensional DFTs. 
Finally, the slaves return their portion of 
the result to the master, which assembles 
the completed transform. 

As an example, consider an implemen¬ 
tation for complex-valued input and 
complex-valued output, with A= 128 and 


Table 2. Armstrong I/O operation 
times (len = message length in 


kilobytes). 

Protocol Type 

Message Time 
(milliseconds) 

Virtual circuit 

_ „ len 

2 ' 8 + ^ 

Datagram 

i iJ en 
' + 400 


Table 3. Armstrong virtual-circuit oper¬ 
ation times. 


Operation 

Time (milliseconds) 

Initialize 


connection 

30.75 

Close connection 

3.15 



Figure 6. Two-dimensional DFT logical communication structure, P = 8. 


June 1988 


47 
















Slave 0 



Figure 7. Two-dimensional DFT data flow, P = 2. 


1 


ZJ 

Master process 

Slave processes 


for (' = 0 to P - 1 / * initialize */ 

/* j = this slave’s identifier (assigned by master) */ 


start slave process i 

connect to slave process i 

initialize connections to all other slaves and to master 


end 

read image from camera or disk 

rows-per-slave = N/P 

receive rows-per-slave rows of image data from master 


rows-per-slave = N/P /* distribute image */ 

for r=0 to (rows-per-slave - 1) /* compute row DFTs */ 


for t = 0 to P - 1 

take one-dimensional DFT of row r 


send rows (/' * rows-per-slave) 

end 


through ((/'+ 1) * rows-per-slave - 1) to slave i 

end 

for /= 1 to P- 1 /* exchange data with other slaves */ 


for i = 0 to P - 1 / * get results */ 

k=j XOR i 

exchange appropriate portion of intermediate result with slave k 

receive columns (/ * rows-per-slave) 

end 


through ((/ + 1) * rows-per-slave - 1) 

from slave i 

for c=0 to (rows-per-slave- 1) /* compute column DFTs 

V 

end 

take one-dimensional DFT of column c 


end 


display results 


return column DFT results to master 



Figure 8. Pseudocode for two-dimensional DFT. 


COMPUTER 















































P= 2, as Figure 7 illustrates. The image 
can be divided into four parts, a, b, c, and 
d, with each subimage measuring 64 x 64. 
The master distributes sections a and b to 
slave 0, and sections c and d to slave 1. 
Each slave then computes 64 one¬ 
dimensional 128-point row DFTs to yield 
intermediate results a', b', c', and d'. 
Next, slave 0 sends intermediate result b' 
to slave 1, while slave 1 sends intermediate 
result c' to slave 0. Then, each slave com¬ 
putes 64 one-dimensional column DFTs, 
slave 0 using the columns formed by a' and 
c', and slave 1 using the columns formed 
by b' and d'. This yields the final results 
A, B, C, and D, which are returned to the 
master. Figure 8 shows pseudocode for the 
master and slave processes. 

The implementation discussed in the 
remainder of this article is somewhat 
different because it accepts real-valued 
input. This allows a savings of approxi¬ 
mately 50 percent in the computation 
required, because when the input is real 
valued, (1) the row DFTs can be computed 
with only half the work, and (2) only half 
the column DFTs need to be done, since 
the output displays complex-conjugate 
symmetry. Flowever, the above descrip¬ 
tion is still essentially accurate. 

The two-dimensional DFT application 
is suitable for parallel implementation in 
that it requires significant computation 
and has much inherent parallelism for 
large values of N. However, it also has 
relatively high I/O requirements. For 
example, consider a 128x 128 (real¬ 
valued) image as input. When the master 
distributes the image to the slaves, a total 
of N 2 intensity values must be transferred 
(16 kilobytes). The matrix transpose 
requires each slave to send one message to 
every other slave, for a total of P{P- 1) 
messages. This requires approximately 
N(N/2) complex double-precision num¬ 
bers to be transferred (128 kilobytes). 
Finally, the slaves return a total of 
N(N /2 + 1) complex double-precision 
numbers to the master (128 kilobytes). 

One main feature of the Armstrong 
operating system is that it allows the logi¬ 
cal communication topology of a program 
to be decoupled from the physical commu¬ 
nication topology. Thus, for our experi¬ 
ments we can use any physical 
configuration to implement the logical 
configuration shown in Figure 6—and 
without even recompiling the application. 

Three different communication net¬ 
works were tested: a binary-hypercube net¬ 
work (Figure 9a), a two-dimensional 
nearest-neighbor mesh (Figure 9b), and a 


□ 


(b) 


(0 



Figure 9. Communication networks: (a) binary-hypercube network, (b) two- 
dimensional nearest-neighbor mesh, (c) binary-tree network with an additional 
node. 
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Figure 10. Speedup on different networks. 



binary-tree network with an additional 
node attached to the root node of the tree 
to make the tree size a power of 2 (Figure 
9c). The application was run for N= 128 
on all three networks, varying P from 1 to 
32. Figure 10 shows the results as the 
speedup (execution time on one node 
divided by execution time on P nodes) 
versus P. The execution time on one node 
was measured using a serial version of the 
program that performed exactly the same 
number of arithmetic operations as the 
parallel version. The results indicate that 
the hypercube network has the best perfor¬ 
mance for this application; the mesh net¬ 
work is a close second. In contrast, the tree 
network performance falls off slightly for 
P= 16 and significantly for P= 32. This is 
because the tree network forms a commu¬ 
nications bottleneck at the top, so all mes¬ 
sages from one half of the tree to the other 
half must pass through the root node. 

Since the hypercube network had the 
best performance, another experiment was 
carried out to compare the performance of 
the application for different values of N. 
Figure 11 illustrates the speedup measured 
for N=64, 128, and 256 on a hypercube 
network, varying P from 1 to 32. 

(Since the transform results for N=256 


are too large to fit in memory, the timings 
for this value were measured with a version 
of the master process that discarded the 
results after they were received from each 
slave. Comparing the timings for this ver¬ 
sion with the those of the unmodified ver¬ 
sion forN= 64 and 128 showed negligible 
differences.) 

This graph indicates that the applica¬ 
tion’s performance improves significantly 
for larger values of N. This would be 
expected, because the computation time 
for the DFT grows as N 2 log 2 N(for con¬ 
stant P), while the amount of data to be 
transferred grows as N 2 . Thus, the I/O 
required per unit of computation is 
inversely proportional to log 2 N and 
decreases as N increases. 

As illustrated, the performance of this 
application does not show a linear increase 
with the number of processors. Two main 
factors prevent such an increase. First, the 
time required for I/O is largely indepen¬ 
dent of the number of processors because 
roughly the same amount of data must 
always be transferred (except when P is 
small). The constant I/O time becomes 
increasingly more important as the time 
required for computation decreases as a 
result of the increased number of proces¬ 


sors. Second, portions of the application 
are serial in nature. The master can distrib¬ 
ute data to and receive results from only 
one slave at a time. Again, these serial por¬ 
tions become increasingly significant as the 
computation time decreases. 

Figure 12 illustrates the effects of these 
factors. The top curveof Figure 12shows 
the elapsed time required for the two- 
dimensional DFT application for N = 128, 
P varying from 1 to 32, using a hypercube 
network. The areas between the other 
curves show the portion of the total time 
required for row and column DFTs, the 
portion required for the interslave trans¬ 
pose, and the portion required for I/O 
between the master and the slaves. For 
P< 4, the transpose and master-I/O times 
are not very significant compared with the 
DFT time. Thus, the application shows a 
near-linear speedup (refer to Figure 11, 
128 x 128 image). As P increases, the time 
required for the transpose and the master 
I/O remain roughly constant, while the 
time for the DFTs drops sharply, because 
the DFTs are perfectly parallelized (since 
there is no interaction between processors 
while they are computed). Thus, the trans¬ 
pose and master I/O take a higher and 
higher proportion of the total elapsed 
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time, and the speedup becomes less and 
less linear. As P approaches 32, the trans¬ 
pose and master-I/O times increase 
slightly because the messages become 
smaller and smaller, and smaller messages 
have proportionally more overhead than 
larger messages. This further detracts 
from the speedup. 

To further illustrate the impact of I/O 
on this application, we have broken the 
application into five phases: distribution 
of the input data, computation of the row 
DFTs, transposition of the intermediate 
data, computation of the column DFTs, 
and collection of the results. During each 
phase, the time spent computing, perform¬ 
ing I/O, and sitting idle, and the time 
wasted on overhead (context-switching 
and scheduling) was measured for the slave 
processes, using a hypercube network and 
N= 128. Figure 13a shows the breakdown 
for P= 4, while Figure 13b shows the 
breakdown for P= 32. 

The “summary” breakdown includes 
all five phases, weighted according to the 
proportion of the total time spent in each 
phase. For both values of P, the row and 



Number of processors 


Figure 12. Elapsed-time breakdown. 



Receive input data 
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Figure 13. Activity distribution by phase: (a) breakdown for P = 4, (b) breakdown for P=32. 
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column DFT phases are completely com¬ 
putation bound, indicating efficient use of 
the system. The most interesting phases are 
the transpose and collection phases. As the 
number of processors changes from 4 to 
32, the total idle time increases signifi¬ 
cantly. In addition, the length of these 
phases increases relative to the total 
elapsed time, making them more signifi¬ 
cant in the overall summary. The 
distribution-phase breakdown is not very 
informative because, for each slave, it 
begins when the first piece of data is 
received from the master and ends when 
the last piece of data is received from the 
master. It should instead start when the 
master starts distributing data to the first 
slave and end when the master finishes dis¬ 
tributing data to the last slave. However, 
this is difficult to do without special hard¬ 
ware on a message-passing system. 

T he Armstrong system is a loosely 
coupled general-purpose multi¬ 
processor system incorporating 
several unique features. The most impor¬ 
tant of these are a reconfigurable I/O 
topology and extensive support for mes¬ 
sage passing, including location- 
independent addressing, arbitrary-length 
messages, error checking and recovery, 
and flow control. Despite its functionality, 
the operating system provides high- 
performance I/O for user applications. 
The measured performance indicates 
extensive speedup through parallelism 
even for an application requiring large 
amounts of I/O relative to its paralleliza- 
ble computational requirements. 

We believe the operating system pro¬ 
vides a reasonable minimal set of services 
to the application programmer. Although 
determining the impact of the operating- 
system software on the application perfor¬ 
mance would be desirable, we have not 
done so. The only way to assess the impact 
would be to write a version of the program 
to run on the “bare hardware,” which 
would require excessive effort for the 
result obtained. In addition, our bare- 
hardware version would probably incor¬ 
porate essentially the same code presently 
in the operating system and thus would 
have similar efficiency. 

Although the Armstrong system is con¬ 
structed with what is no longer leading- 
edge hardware (16-bit data paths, twisted¬ 
pair communications, medium-size mem¬ 
ory), it enables us to perform experiments 
with real hardware and to vary many of the 
system parameters for further research. 
We are confident that the results obtained 


with the current hardware are extensible to 
future multiprocessor systems. Future 
work on the Armstrong system will involve 
writing more applications and evaluating 
their performance. Parallel applications 
currently under development or completed 
include robot control, simulated anneal¬ 
ing, and Kalman filtering. □ 
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Traditional, Semantic, and 
Hyper-Semantic Approaches 
to Data Modeling 

Walter D. Potter, University of Georgia 
Robert P. Trueblood, University of South Carolina 


W hen the automated data pro¬ 
cessing era began in the 1950s 
and early 1960s, many organi¬ 
zations started transferring their manual 
operations to computerized systems that 
offered economical, high-speed, accurate 
data processing. This conversion was suc¬ 
cessful, but problems arose concerning 
data availability. It became difficult for a 
user “to obtain, integrate, or transform 
the available data” for various uses. 1 

The notion of integration gave rise to 
the concept of a generalized database 
management system. The DBMS, in turn, 
needed a formalism to express the data’s 
logical structure and use. This formalism 
is called a data model. 

The objective of a data model is to rep¬ 
resent, as accurately as possible, the fun¬ 
damental real-world concepts necessary 
for structuring the information an organ¬ 
ization uses. One of the earliest formalisms 
viewed an organization as being composed 
of a collection of entities. 

An entity can be an object (that is, a per¬ 
son, place, or thing) or an event (for exam¬ 
ple, hiring a person for a particular job) 
about which information is to be stored. 
The stored information is viewed as a col¬ 
lection of values for attributes describing 
the properties of an entity. 

The data model must identify the set of 
entities of an organization and also cap¬ 
ture the relationships among the entities 
within the organization. For example, the 


j 

Data models define 
the formal structure of 
advanced information 
systems. Early models 
were computer 
oriented; more recent 
user-oriented 
approaches capture 
inferential 
relationships among 
real-world concepts. 


entity people is related to the entity job 
position in the context that an organiza¬ 
tion hires a person to fill a position. 

Today, entities, their relationships, and 
other pertinent information necessary for 
an organization to operate are collectively 
referred to as operational information. 
When modeling an organization, the oper¬ 
ational information is often represented in 
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an outline or diagram called a schema , a 
structural representation of the informa¬ 
tion. (This is illustrated in the section enti¬ 
tled “Traditional data models.” Further 
information about data models can be 
found in the literature. 3 ' 5 ) 

This article overviews past and present 
data-modeling trends and identifies future 
directions. We cover a broad spectrum of 
modeling approaches to give you a feel for 
the richness and diversity of data model¬ 
ing. Specifically, we review the three tra¬ 
ditional and commonly used data models 
that gained wide acceptance in the late 
1960s and early 1970s and are used exten¬ 
sively today; we describe semantic data 
models that attempt to enhance the repre¬ 
sentation of operational information by 
capturing more of the meaning about data 
values and relationships; we discuss novel 
enhancements to semantic data models 
that characterize the new field of hyper- 
semantic data models and emphasize cap¬ 
turing inferential relationships; and we 
look at data-modeling trends. 

A common example is used throughout 
the article to illustrate the various proper¬ 
ties and/or features of different data 
models. The example is based on model¬ 
ing a university situation; we introduce it 
next by identifying some common entities 
and relationships. 

University example. Suppose you want 
to model a university environment where 

53 


June 1988 












SNO SNAME SMAJOR LGRADE CCODE CNAME CHRS 


Legend 

□ 

Entity 

o 

Relationship 

_ 

Entity-relationship 


connection 


Figure 1. An entity-relationship diagram. 


SNO 

SNAME 

SMAJOR 

SI 

Ron 

Computer Science 

S2 
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Mathematics 

S3 

Kim 

Computer Science 

S4 

Bob 

Electrical Engineering 


COURSES 



students enroll in courses taught by faculty 
members and receive grades for the 
courses taken. Since information about 
students, courses, and grades is to be 
stored, two entities (STUDENTS and 
COURSES) are readily identified. The 
attributes or properties that describe the 
STUDENTS entity are student identifica¬ 
tion number (SNO), student name 
(SNAME), and major (SMAJOR). The 
COURSES entity has the attributes course 
code (CCODE), course name (CNAME), 
and number of credit hours (CHRS). Since 
students can be distinguished from one 
another (such as, by their identification 
numbers), the collection of all students in 
the university forms an entity set. That is, 
elements of an entity set have the same 
properties (attributes) but are distinguish¬ 
able. Likewise, there is an entity set for 
courses. 

A relationship between STUDENTS 
and COURSES exists in that students take 
courses. These entities and relationships 
are illustrated in Figure 1 where the rela¬ 
tionship is named GRADES. A student 
may take several courses, and a course 
may be taken by many students. This 
many-to-many relationship is denoted by 
the “ M ” and “ N ” on the arcs from STU- 
DENTS to GRADES and from 
COURSES to GRADES, respectively. An 
attribute of the relationship GRADES is 
the letter grade (LGRADE) received by 
each student in each course. In Figure 1, 
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the attributes are labeled arcs extending 
from the entity or relationship to which the 
attribute belongs. 

The illustration in Figure 1, called an 
entity-relationship diagram, provides a 
graphical method for logical database 
specification. The method is referred to as 
the entity-relationship (E-R) model. 4 

With respect to the GRADES relation¬ 
ship, each letter grade can be identified by 
the pair (SNO, CCODE). Each pair of stu¬ 
dent identification numbers and course 
codes is a relationship and the set of all 
such pairs is called a relationship set. 


Traditional data models 

The three traditional data models are 
the relational model, the hierarchical 
model, and the network model. Next, we 
describe the basic structure and the vari¬ 
ous aspects of manipulation languages for 
them. 


The relational data model. Many of the 
basic concepts and definitions for the rela¬ 
tional data model were first introduced by 
Codd 6 ; the text by Date provides an excel¬ 
lent introduction to the relational data 
model 7 ; and a more mathematical discus¬ 
sion of the relational data model can be 
found in the text by Maier. 8 

The relational data model is composed 
of three aspects: structure, integrity, and 
manipulation. From a user viewpoint, the 
structure of a relational model is a collec¬ 
tion of tables called relations. Figure 2 
gives three relations for the university 
example. Each relation (table) cor¬ 
responds to an entity type or relationship 
type. In Figure 2, STUDENTS and 
COURSES are entity relations and 
GRADES is a relationship relation. The 
rows of a table are called tuples and rep¬ 
resent instances or occurrences of the 
entity or relationship (that is, elements of 
the entity set or relationship set). 

For example, the tuple (row) 
“SI—Ron—Computer Science” in the 
STUDENTS relation of Figure 2 denotes 
an instance of the STUDENTS entity. The 
columns of the table are the attributes of 
the entity type. The set of all possible 
values that can appear in a given column 
is called the domain of the attribute. The 
relationship between STUDENTS and 
COURSES is represented by the GRADES 
relation. The STUDENTS relation is 
related to the GRADES relation via the 
common (shared) domain of the attribute 
SNO. 


In general, a table is associated with 
another table by attribute values in their 
respective columns that are drawn from a 
common domain. In Figure 2, STU¬ 
DENTS and GRADES are associated via 
the SNO domain that is common to both 
relations. Similarly, COURSES and 
GRADES are associated via CCODE. 

If the attribute SNO has unique and 
defined (non-null) values for each instance 
of STUDENTS, SNO may serve as the pri¬ 
mary key of the STUDENTS relation. 
Similarly, CCODE may serve as the pri¬ 
mary key for COURSES. For the 
GRADES relation, SNO together with 
CCODE uniquely identify instances of the 
relationship between the STUDENTS and 
GRADES relations. 

In general, a relationship relation con¬ 
tains the primary key attributes of the enti¬ 
ties involved, and together these attributes 
serve as the primary key of the relationship 
relation. 

The integrity aspect of the relational 
data model consists of two basic rules: 
“entity integrity” and “referential 
integrity.” 7 

The entity integrity rule states that an 
attribute value of a primary key may not 
be null (that is, every occurrence has values 
for its primary key attributes). The pri¬ 
mary key of a relation is composed of one 
or more attributes that serve as unique 
identifiers for each entity occurrence. If 
the primary key of STUDENTS in the uni¬ 
versity example is SNO, then the entity 
integrity rule means that a tuple represent¬ 
ing a student cannot exist in the STU¬ 
DENTS relation unless that student has a 
unique identification number. 

The referential integrity rule states that 
if an attribute of one relation, say R1, par¬ 
ticipates in the primary key of another 
relation, say R2, then the set of values for 
the attribute in R1 is a proper subset of the 
set of attribute values in R2. This rule sim¬ 
ply means that if one instance of an entity 
exists and refers to another entity occur¬ 
rence, then the referenced entity occur¬ 
rence must also exist. For example, the 
SNOs in the GRADES relation in Figure 
2 are a subset of the SNOs in the STU¬ 
DENTS relation. 

In addition, researchers have proposed 
the extension of the relational model by 
including other aspects of integrity. 3 ' 7 
These extensions include such features as 
data type checking, enforcement of “no 
nulls” and/or duplicate attribute values 
allowed, and the attachment of predicates. 
These features are addressed in the sec¬ 
tions entitled “Semantic data models” and 


“Hyper-semantic data models.” 

The data manipulation aspect of the 
model can be divided into two major 
classes 7 : relational algebra and relational 
calculus. 

The relational algebra consists of the set 
operators—union, intersection, and 
difference—along with special operators 
such as select, project, and join. Each 
operator takes one or more operands and 
produces a new relation as its result. To 
query the database, one writes a sequence 
of relational algebra operators. Because of 
this, relational algebra is referred to as a 
high-level procedural language. 

The relational calculus is based on first- 
order logic or predicate calculus. To query 
the database, one writes a predicate calcu¬ 
lus statement (formula) that defines the 
desired results. 

It has been shown that these two lan¬ 
guages are equivalent in retrieval power or 
capacity. 

Figure 3 gives an example query using 
relational algebra and relational calculus 
to extract data from the relations in Figure 
2. The query language Quel used for the 
Ingres relational database management 
system and IBM’s QBE used for the QMF 
system are based on relational calculus. 
The query language for R:base 5000 from 
Microrim and dBase III from Ashton-Tate 
are based on relational algebra. In addi¬ 
tion, the data manipulation language 
SQL, which is used for IBM’s DB2 system, 
is a blend of relational algebra and rela¬ 
tional calculus. 7 An example of SQL is 
given in Figure 3. 

The hierarchical data model. The hier¬ 
archical data model is the oldest traditional 
data model. Much of the model’s develop¬ 
ment and implementation has been done 
by IBM in its information management 
system (IMS) software packages and by 
MRI Systems Corp. in its System 2000. 

The hierarchical data model is based on 
the idea that much of the real world can be 
perceived and organized as a hierarchical 
structure. For example, the classification 
of job titles follows the hierarchy of presi¬ 
dent, vice presidents, managers, etc. The 
hierarchical model captures these relation¬ 
ships in terms of hierarchical definition 
trees. 

In a hierarchical definition tree, the sub¬ 
trees are ordered and the direction of an 
arc is from parent to child. Each node of 
the tree denotes an entity type, called a rec¬ 
ord type , composed of one or more attrib¬ 
utes, called data items that describe the 
entity. 
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Query in English: 

Get the names of those students who received an A grade for the courses 
they have taken. 


Query in relational algebra: 

Join STUDENTS and GRADES over SNO giving Temp 1. 

Select from Tempi where LGRADE = ‘A’ giving Temp2. 

Project SNAME from Temp2 giving result. 

Explanation: The Join procedure combines the rows in the STUDENTS 
table with the rows in the GRADES table where the SNOs are the same in 
both tables. The Select procedure extracts those rows in which students 
received an A in the course. The Project procedure extracts only the 
SNAME column. 


Query in relational calculus: 

RANGE SX IS STUDENTS 
RANGE GX IS GRADES 

(SX.SNAME where 3GX(SX.SNO = GX.SNO 
AND GX.LGRADE = ‘A’)) 

Explanation: The relational calculus query may be read as follows: Get 
SNAME values in STUDENTS (SX) such that there exists a grade in 
GRADES (GX) for which that student received an ‘A’ grade. 


Figure 4 illustrates a possible hierarchi¬ 
cal definition tree for the university exam¬ 
ple. The relationship between two entities 
is denoted by the parent-child arc. The 
parent-child relationship automatically 
supports referential integrity in the sense 
that no instance of a child record can exist 
without the existence of a parent record. 

Data manipulation within the hierarchi¬ 
cal model makes extensive use of the 
parent-child relationship and the ordering 
of the subtrees. Examples include such 
operations as Get Next and Get Next 
Within Parent found in the data manipu¬ 
lation language DL/1 (used within IMS). 

There are several limitations of the hier¬ 
archical data model. One limitation is that 
there is no direct way to represent many- 
to-many relationships (for example, 
siblings with two parents). IMS addresses 
this problem through constructs called log¬ 
ical child and logical parent. Another limi¬ 
tation is that deleting a parent record 
instance automatically deletes all of the 
corresponding child-record instances. 

Depending on the application being rep¬ 
resented by the hierarchical model, the 
data contained in the child-record 
instances may or may not need to be 
retained. In addition, the handling of some 
queries can become difficult if the queries 
do not conform to the hierarchical 
structure. 


Query in SQL: 

SELECT SNAME 
FROM STUDENTS, GRADES 

WHERE STUDENTS. SNO = GRADES.SNO 

AND LGRADE = ‘A’ 


Figure 3. Example of relational algebra, relational calculus, and SQL. 


CO URSES __ 

| CCODE | CNAME | CHRS | 


G RADES X _ S TUDENTS j _ 

[ SNO | LGRADE | | SNO | SNAME | MAJOR| 


Figure 4. Hierarchical definition tree. 


The network data model. The network 
data model (or CODASYL model) is 
based on the 1971 report published by the 
CODASYL Data Base Task Group. 4 The 
objective of the report was to designate 
language and system specifications for a 
DBMS that could be embedded within the 
Cobol programming language. Since this 
original report, further model refinements 
and clarifications have been made. The 
book by Olle is devoted to the subject of 
network data models. 9 

In the network data model, each entity 
type is described by a record-type defini¬ 
tion. The definition gives the record a 
name and defines the fields of the record 
that represent the attributes of the entity 
being specified. The relationship between 
two entities is defined as a set type. A set 
(not the same as a mathematical set) is 
composed of an owner record type and a 
member record type. Figure 5 illustrates a 
network model with two sets for the uni¬ 
versity example. Although not necessary, 
the SNO and CCODE of GRADES are 
shown in Figure 5 for clarity. 

Structurally, an instance of an owner 
record type can be viewed as the root of a 
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Figure 5. A network model for the university example. 


two-level tree with member instances as 
leaves. Implicitly, the set provides a one- 
to-many mapping relationship. To form 
complex structures and to provide for 
many-to-many relationships, sets are 
allowed to intersect. 

Set intersection is restricted to either 
having members shared between two sets 
or having a member of one set as the owner 
of one or more other sets. The restriction 
preserves the set definition and does not 
prohibit the specification of relationships 
between the entities. 

Record types and set types are specified 
by a data-definition language that defines 
the schema and subschemas for a data¬ 
base. In most CODASYL DBMSs, such as 
the integrated database management sys¬ 
tem (IDMS) produced by Cullinet Soft¬ 
ware, the data-definition language looks 
like a collection of Cobol record defini¬ 
tions with the addition of set specifica¬ 
tions. Figure 6 gives a sample 
data-definition language specification for 
the STUDENTS and the STUDENTS- 
GRADES set. 

A data manipulation language is used to 
access (read, write, or modify) the data¬ 
base. The data-manipulation language 
makes use of navigation operations such 
as Find Next record, Find Prior record, 
Find Member, and Find Owner. Within 
the DBMS software, these operations 
make use of cursors or currency indicators 
to denote which set, record types, and 


SCHEMA NAME IS STUDENTS-COURSES-GRADES. 

RECORD NAME IS STUDENTS 
LOCATION MODE IS CALC USING SNO 
DUPLICATES NOT ALLOWED. 

02 SNO PIC X(5) 

02 SNAME PIC X(20) 

02 SMAJOR PIC X(10) 

SET NAME IS STUDENTS-GRADES. 

ORDER IS NEXT. 

OWNER IS STUDENTS. 

MEMBER IS GRADES MANDATORY AUTOMATIC 


Remarks: 

(1) The LOCATION MODE ... identifies SNO as the 
primary key stored and located by hashing (CAL¬ 
CULATED). 

(2) The ORDER IS NEXT and MANDATORY AUTO¬ 
MATIC statements cause new occurrences of 
GRADES to be included in the current record of the 
current set. 


Figure 6. A sample data-definition language. 
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INSTRUCTORS(S) = TAUGHT-BY(ENROLLED-IN(S)) 


legend 

-> Single-valued 
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Figure 7. Derived relationship example. 


instances are being processed by the 
DBMS. The data-manipulation language 
allows these cursors to be indirectly 
addressed via the Current Of option. 

Semantic data models 

The traditional data models are basi¬ 
cally record-oriented models. The devel¬ 
opment of these models was motivated 
and influenced by primitive file-system 
implementation concerns. 10 For example, 
this can be seen in a relational database 
management system where the tuples in a 
relation correspond to the records of a file. 

The development of models that 
provided more user-oriented modeling 
flexibility without being constrained by an 
implementation structure was the primary 
goal of early semantic data model 
researchers. 5,11,12 These models provide a 
“natural” mechanism (that is, similar to 
the way a user or system designer views an 
application) for specifying the design of a 
database (as represented by the conceptual 
schema or overall design view) and more 
accurately representing the data and rela¬ 


tionships among the data than the tradi¬ 
tional models. 4,13 

Semantic data models allow database 
designers to represent the objects of 
interest (such as students, courses, and 
instructors) in an application and their 
relationships (such as students 
ENROLLED-IN courses and courses 
TAUGHT-BY instructors) in a way that 
more closely resembles the view the user 
has of these objects and relationships. 

For example, designers are freed of the 
need to model a variety of different situa¬ 
tions with just one modeling construct, 
such as the parent-child relationship found 
in the hierarchical model that would be dif¬ 
ficult to use in modeling the GRADES 
relationship between STUDENTS and 
COURSES. 

Trying to model a variety of relation¬ 
ships with only one modeling construct 
typically results in the loss of the exact 
meaning of the relationships (as shown on 
p. 122 of Yao 5 ). Consequently, the appli¬ 
cation design often falls far short of 
modeling the user’s actual situation. 

Semantic data models provide powerful 
abstraction constructs, such as generaliza- 



in the traditional data models. 1 


Generalization allows the designer to 
group similar objects together to concen¬ 
trate on the more general group object, as 
in the example of viewing GRADUATE 
and UNDERGRADUATE students in the 
same student-body group called 
STUDENTS. 

Aggregation allows the designer to 
model an abstract object based on the 
properties or attributes of the object. For 
instance, the aggregate object ADDRESS 
is composed of STREET, CITY, STATE, 
and ZIPCODE. 

Other abstraction constructs have been 
associated with semantic data models, but 
generalization and aggregation are 
regarded as the most widespread among 
the models. 13 

In addition to the generalization and 
aggregation constructs, semantic data 
models are characterized by the notion of 
“derived data.” Essentially, derived data 
can be thought of as data values that are 
not actually stored in the database but are 
produced or derived when needed from 
existing data and relationships. 

For example, an INSTRUCTORS rela¬ 
tionship between STUDENTS and 
FACULTY represents those faculty mem¬ 
bers currently associated with a student via 
the student’s enrollment in courses taught 
by the faculty members. In Figure 7, the 
ENROLLED-IN attribute identifies the 
enrollments of each student and the 
TAUGHT-BY attribute identifies the 
faculty teaching the courses currently 
being offered. By applying the TAUGHT- 
BY attribute to those courses 
ENROLLED-IN by a particular student, 
we are able to derive the INSTRUCTORS 
currently associated with the student (note 
that duplicates will occur if a student is 
taking more than one course taught by a 
particular faculty). 

The storing of explicit instructors is 
unnecessary because the relationships and 
means exist for deriving this data. The 
INSTRUCTORS attribute may be easily 
defined as 

INSTRUCTORS(S) = TAUGHT- 

BY(ENROLLED-IN(S)) {for all S in 

STUDENTS} 

Semantic data models are classified 
according to three general categories: rela¬ 
tional, functional, and semantic-network. 

Models in the relational category are 
basically extensions to the relational data 
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model. The functional models have an 
equally strong mathematical influence. In 
these models, the function is the primary 
notation used to represent and manipulate 
objects and relationships. For example, 
applying the ENROLLED-IN attribute (or 
function) to a particular student returns 
the set of courses that the student is cur¬ 
rently enrolled in. 

The semantic-network type models have 
a close relationship to the semantic- 
network knowledge-representation for¬ 
malism (a structural approach to organiz¬ 
ing knowledge using nodes and arcs to 
represent objects and relationships) found 
in the artificial intelligence field. 

These models emphasize a minimal 
amount of data redundancy and alternate 
views of the data. 

Presently, there is only one commer¬ 
cially available semantic database manage¬ 
ment system; called SIM, it’s available 
from Unisys Corp. Research activity in the 
area of physical implementations of 
semantic data models has been increasing 
over the past several years. Several proto¬ 
type implementations are aimed at provid¬ 
ing the semantic data model constructs 
discussed previously (that is, generaliza¬ 
tion and aggregation) as well as providing 
enhanced graphical user interface and 
metadata (the description of the data) 
manipulation facilities. 14 

Recently, the functional data-modeling 
approach has received increased attention 
because of the current trend to investigate 
implementations that exploit the object- 
oriented features of semantic data models. 
In general, these features include 

(1) identifying any concept or thing as 
an object, 

(2) organizing objects into object-types 
or classes, 

(3) organizing object-types via generali¬ 
zation, aggregation, and user- 
defined relationships, and 

(4) allowing property inheritance within 
generalization hierarchies. 

The functional approach facilitates 
these research efforts due to the modeling 
primitives that allow the relationships 
between objects of interest in the real- 
world situation to be captured and related 
to an implementation strategy (for exam¬ 
ple, attribute(object) = value). 

These are referred to as object-oriented 
database management systems. 14 They 
combine organizational features of seman¬ 
tic data models with the operational (that 
is, object and property behavior) features 
of object-oriented programming. This 
marriage provides systems that promise to 


easily handle a variety of information that 
would be very difficult for traditional 
database systems to handle. Examples of 
this type of information include voice 
data, engineering-drawing data, multiple- 
document versions, graphics data, and 
spatial-orientation data. 

Hyper-semantic data 
models 

Present-day automated information 
systems often rely heavily on some type of 
database management system for sup¬ 
port. 7 From an implementation perspec¬ 
tive, a DBMS attempts to represent a 
real-world information management situ¬ 
ation within the framework of one of the 
traditional data models. However, these 
models are very restrictive in terms of flex¬ 
ibility because of their limited constructs 
and implementation influence. Semantic 
data models extend this flexibility by 
providing powerful abstraction constructs 
and implementation independent model¬ 
ing capabilities. In other words, they cap¬ 
ture more of the meaning of the user 
application. 

The motivation behind the development 
of hyper-semantic data models is simply 
the need to capture even more of an appli¬ 
cation’s meaning. Designers want models 
that accurately represent their situation in 
a manner that is over and above the model¬ 
ing capabilities provided by semantic data 
models. This is accomplished by providing 
an extended set of modeling constructs, a 
unified formalism for handling these con¬ 
structs (that is, a consistent method for 
representation and manipulation), and 
capabilities for multilevel data manage¬ 
ment (that is, data and metadata 
management). 

Hyper-semantic data models focus on 
capturing the objects, operations, relation¬ 
ships, and knowledge associated with an 
application. Objects are the specific con¬ 
cepts, things, or entities—such as students 
and faculty—that are dealt with in an 
information system. Operations are the 
management services of a DBMS—such as 
creation, deletion, or modification—that 
directly affect an object in some manner. 

Objects and operations are involved in 
relationships that provide modeling 
accuracy or model the information system 
via various abstraction mechanisms, such 
as graduate students defined as a subtype 
of students. Knowledge encompasses the 
implicit and explicit restrictions placed 
upon objects, operations, and relation¬ 


ships along with general and specific 
heuristics and inference procedures 
involved in the situation being modeled. 

For example, the number of students 
that may enroll in a course is restricted to 
the capacity of the classroom where the 
course is to be taught, or a faculty mem¬ 
ber may be characterized as distinguished 
if he or she fulfills some criteria. Captur¬ 
ing these knowledge semantics is the major 
emphasis of the artificial intelligence sub¬ 
field called knowledge-based systems. 15 

In short, hyper-semantic data models 
extend the capabilities of semantic data 
models by incorporating features taken 
from the knowledge-based systems area 
(such as inference) and extend the capabil¬ 
ities of knowledge-based systems by incor¬ 
porating features of semantic data models 
(such as providing for a large data 
capacity). 

As mentioned previously, semantic data 
models typically provide generalization 
and aggregation constructs. The modeling 
constructs that characterize hyper- 
semantic data models include 

(1) generalization, where similar object- 
types are abstracted into a higher 
level object-type via the “is-a” rela¬ 
tionship (for example, the object- 
type “programmers” is a sub-type 
of the “employees” object-type); 

(2) classification, where specific 
instances are considered as a higher 
level object-type via the “is- 
instance-of” relationship (for exam¬ 
ple, “Columbia” and “Enterprise” 
are specific instances of “space- 
shuttles”); 

(3) aggregation, where an object is 
related to the components that make 
it up via the “is-part-of” relation¬ 
ship (for example, an “employee” 
has a “name,” “address,” and 
“social security number”); 

(4) membership, where several object- 
types are considered as a higher level 
set object-type via the “is-a- 
member-of” relationship (for exam¬ 
ple, “attack-force” is a set object- 
type with member object-types 
“land-assault-team” and “air- 
assault-team”); 

(5) constraint, where a restriction is 
placed on some aspect of an object, 
operation, or relationship via the 
“is-constraint-on” relationship (for 
example, each student classification, 
such as freshman, sophomore, jun¬ 
ior, or senior, is bounded by the 
number of course credit hours com¬ 
pleted); 
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Figure 8. Academic knowledge/data schema. 


(6) heuristic, where an information 
derivation mechanism is attached 
via the “is-heuristic-on” relation¬ 
ship (for example, the courses to be 
taken next term by a student are 
inferred from information about the 
courses required for the student’s 
degree program, the courses already 
taken by the student, and the courses 
being offered next term); and 

(7) temporal, where specific object- 
types are related by synchronous or 
asynchronous characteristics and 
considered as a higher-level object- 


type (for example, the modeling of 
graduate degree hurdles such as the 
completion of core courses prior to 
taking a qualifying exam that is fol¬ 
lowed by independent study and the¬ 
sis work). 


New modeling primitives. Hyper- 
semantic data models support the major 
constructs of semantic data models (gener¬ 
alization and aggregation) as well as two 
minor constructs (classification and mem¬ 
bership). In addition, they provide con¬ 
straint, heuristic, and temporal constructs. 


These additional modeling primitives 
address the relationships between objects 
that are respectively restrictive, inferential, 
and chronological in nature. These rela¬ 
tionships, captured within an information 
system situation, are the characteristics 
that distinguish the class of hyper-semantic 
data models. 

The temporal relationship primitive is 
provided by an abstraction mechanism 
based on the notion of synchronous and 
asynchronous objects or object-types. 
This feature is primarily directed toward 
the specification of tasks or events that, for 
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example, are objects dealt with in office 
information systems. Synchronous objects 
are related to other synchronous objects by 
either the predecessor or successor rela¬ 
tionship. 

At all times, an individual synchronous 
object is associated with the immediate 
predecessor and successor objects. This 
notion can be visualized as being similar to 
a node in a doubly linked list. Synchronous 
objects can be linked to form a single 
higher-level object that may also be viewed 
as a synchronous-type object or an 
asynchronous-type object. Asynchronous 
objects are related to other asynchronous 
objects by a concurrent or parallel notion. 
Asynchronous objects are characterized 
by a trigger or precondition that initiates 
it, an action or procedure to be performed, 
and a postcondition that may involve the 
initiation of another object or the satisfac¬ 
tion of a set of conditions that may trigger 
another object. 

A constraint-type object is associated 
with objects or object-types via the “is- 
constraint-on” relationship. Likewise, a 
heuristic-type object is associated with 
objects or objects-types via the “is- 
heuristic-on” relationship. These relation¬ 
ships provide the designer with a facility 
for defining object restrictions, specifica¬ 
tions, and/or additional (inferred) infor¬ 
mation regarding the nature of an object. 

Both implicit (such as, a specified cardi¬ 
nality of a set-type object-type) and 
explicit (such as, a restriction on a value of 
an object’s attribute) constraints may be 
defined as well as object-type and attrib¬ 
ute heuristics (for example, the strength of 
an academic department is inferred from 
a set of faculty characteristics and degree 
requirements). 

This is due to the fact that, in general, 
hyper-semantic data models allow access 
to data (that is, values of attributes), 
metadata (that is, the description of the 
information system, also known as the 
schema), knowledge (that is, constraints or 
heuristics), and meta-knowledge (that is, 
constraints and heuristics that apply to 
objects that are themselves constraints or 
heuristics) in a unified manner. This means 
that, regardless of the kind of data being 
addressed, the access and representation 
formalisms are the same. 

Constraints, heuristics, and temporal 
objects may be generalized, aggregated, or 
considered as higher-level abstract objects 
by using another abstraction mechanism. 
This result provides a consistent mecha¬ 
nism for specifying, controlling, and 
organizing these constructs. This 


approach for handling constraints and 
heuristics provides much greater modeling 
flexibility than the current data- 
base/knowledge base management 
approaches; such approaches involve hav¬ 
ing the constraints completely separated 
from the database in an application pro¬ 
gram or having the heuristics placed in a 
knowledge base that is separate from (or 
loosely coupled to) the database. 

Contributions. The hyper-semantic 
data-modeling area is characterized by 
extensions to the semantic data-modeling 
area and to the knowledge-based systems 
area. Extensions to the semantic data- 
modeling area are 

(1) the incorporation of heuristics to 
model inferential relationships, 

(2) the capability to organize these 
heuristics and to associate them with 
the specific items involved in the 
inferential relationships, 

(3) the capability to incorporate heuris¬ 
tics in a tightly coupled (unified) 
manner, 

(4) the capability to incorporate con¬ 
straints in a tightly coupled (unified) 
manner, and 


(5) the extension of the notion of 
inferred items to include inferred 
objects instead of just inferred 
attribute values. 

The primary contributions to the 
knowledge-based systems area include 

(1) a unified representational formalism 
for knowledge and data, 

(2) a mechanism for providing a large 
data capacity in a knowledge-base 
management system, and 

(3) a mechanism that allows for abstract 
knowledge typing (handling 
rules/constraints as objects). 

In addition, hyper-semantic data 
models typically provide for a unified view 
of, control of, and access to data, 
metadata, knowledge, and meta¬ 
knowledge. The specific goal of this new 
area is to support the design and develop¬ 
ment of expert database systems. 16 

An example. The following example 
shows the schema specification for a small 
academic knowledge/database system that 
expands the previous example. The 
schema diagram showing the object-types 
(rectangles) and attributes (arcs) of interest 
is presented in Figure 8. 
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OBJECT-TYPE: courses-offered HAS 
ATTRIBUTES: 

taught-by: faculty; 
hours: INTEGER; 
title: STRING; 

prerequisites: SET OF courses-offered; 
core-course: BOOLEAN 
WITH HEURISTICS 
IF prerequisites(C) IS EMPTY 
THEN core-course(C): = TRUE; 

/* course C in courses-offered is a 
/♦core course if no prerequisites exist 
advanced-course: BOOLEAN 
WITH HEURISTICS 
FOR ALL X IN prerequisites(C): 

IF prerequisites(X) IS EMPTY 
THEN advanced-course(C): = FALSE; 
/♦advanced courses have prerequisite 
/* courses that have prerequisites 
core-requisites: SET OF courses-offered 
WITH HEURISTICS 


IF core-course(C) IS TRUE 
THEN core-requisites(C): = EMPTY, 

/ * core courses have no core-requisites 
IF core-course(C) IS NOT TRUE AND 
FOR ALL X IN prerequisites(C): 

IF core-course(X) IS TRUE 

THEN core-requisites(C) INCLUDES X, 

/* the core-requisites of a course 
/♦ include its core course prerequisites 
IF core-course(C) IS NOT TRUE AND 
FOR ALL X IN prerequisites(C): 

IF core-course(X) IS NOT TRUE 

THEN core-requisites(C) INCLUDES core-requisites(X) 

/* core requisites of a course are the courses 

/♦that are core prerequisites of the course 

/* plus the core requisites of the non-core 

/♦prerequisites 


INSTANCES: 

co06, co07, co08, co09, colO 
END-OBJECT-TYPE 


Figure 9. Courses-offered object-type. 


Table 1. COURSES-OFFERED—Standard attributes. 


ID 

TAUGHT-BY 

HOURS 

TITLE 

PREREQUISITES 

co06 

pOl 

03 

CS-511 

{} 

co07 

pOl 

03 

CS-513 

{} 

co08 

pOl 

03 

CS-710 

{co07} 

co09 

p02 

03 

CS-750 

{co08, colO} 

colO 

p02 

03 

CS-720 

{co06, co07} 

Table 2. 

COURSES-OFFERED—Inferred attributes. 


ID 

TITLE 

CORE¬ 

ADVANCED- 

CORE¬ 



COURSE 

COURSE 

REQUISITES 

co06 

CS-511 

true 

false 

{} 

co07 

CS-513 

true 

false 

{} 

co08 

CS-710 

false 

false 

{co07} 

co09 

CS-750 

false 

true 

{co06, co07} 

colO 

CS-720 

false 

false 

{co06, co07} 


The important object-types are PER¬ 
SON, FACULTY, STUDENT, 
COURSES-OFFERED, STUDENT- 
COURSE, and GRADES. Generaliza¬ 


tion/specialization relationships exist 
between the PERSON and FACULTY 
object-types and between the PERSON 
and STUDENT object-types as indicated 


by the subtype relationship that is enclosed 
in parentheses in Figure 8. 

An interesting aspect of the example is 
the amount of data actually defined for the 
schema example and the total information 
content (data present plus the data deter¬ 
mined via derivation and inference proce¬ 
dures) available. For instance, the inferred 
attributes of the COURSES-OFFERED 
object-type provide additional informa¬ 
tion regarding a course. This information 
is not stored, but is determined when 
needed. 

On the other hand, standard attribute 
values such as the titles of courses offered 
are stored and maintained. The 
abbreviated COURSES-OFFERED 
object-type specification is presented in 
Figure 9. It shows the attributes and their 
attached heuristics used for determining 
the attribute values. Each instance (that is, 
object identifier such as co06 and co07) is 
associated with stored values of each of the 
standard attributes (but not with the 
inferred attributes, at this time). These 
values are represented in Table 1. 

The set-valued PREREQUISITES 
attribute contains references to course 
identifiers (for example, course object 
co08 has a prerequisite course identified as 
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course object co07 that refers to the 
CS-513 course). The TAUGHT-BY attrib¬ 
ute values are object identifiers that relate 
to instances in the FACULTY object-type 
that are also instances in the PERSON 
object-type. 

The total information content of the 
object-type includes the above standard 
attributes values and the inferred values 
for each course’s CORE-COURSE, 
ADVANCED-COURSE, and CORE¬ 
REQUISITES attributes. The inferred 
values, along with the identifier and title 
values, are represented in Table 2. 

A request to retrieve the Boolean value 
of the CORE-COURSE attribute for the 
CS-513 course prompts the attached heu¬ 
ristic to be invoked and evaluated. That is, 
the prerequisites of CS-513 are retrieved 
and the resulting set is checked for ele¬ 
ments. If no elements are in the resultant 
set, the course is considered to be a core¬ 
course (that is, CORE-COURSE value is 
true for CS-513). 

A request to retrieve the core-requisites 
of CS-750 causes the inference mechanism 
to invoke the attached heuristic that causes 
the CORE-COURSE attribute to be 
invoked. If this attribute evaluates to true, 
then the set of core-requisites is empty. 
However, if the set is not empty, the core¬ 
requisites for the courses in the set are 
determined (recursively, if necessary) until 
all subordinate prerequisites evaluate to 
core courses. CS-511 and CS-513 are the 
core-requisites for CS-750. 

T he data models discussed in this 
article may be classified into four 
distinct groups characterized by 
increasing levels of abstraction within the 
modeling formalism. 

The first group, which corresponds to 
the original computerized filing systems, 
deals strictly with entities and relation¬ 
ships. These early information systems 
tried to model entities and relationships at 
the physical file-level of the computer. 

The lack of integration (as well as many 
other drawbacks) led to modeling entities 
and relationships via a formal structure 
such as trees, tables, etc. This effort was 
an attempt to gain independence from the 
internal computer organization. Models in 
this group attempted to “shoehorn” the 
real-world situation into one of the formal 
data structures. 

The third group, the semantic data 
models, emphasize a more conceptual 
point of view through the use of increased 
abstraction. Primarily, they focus on an 
entity and its properties. This attention on 


the entity is referred to as attempting to 
capture more of the meaning of the real- 
world situation. 

The fourth group continues the efforts 
to capture more meaning by incorporating 
the notion of knowledge, the inferential 
and constraining relationships among 
entities. 

The future will see the definition of var¬ 
ious knowledge/data models and efforts 
to implement systems based on these new 
models. □ 
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Programming in VS Fortran 
on the IBM 3090 for 
Maximum Vector 
Performance 

Bowen Liu and Nelson Strother 
IBM Research Division 


T he IBM 3090 — a high- 
performance, general-purpose 
computer—when enhanced by 
the Vector Facility and the VS Fortran 
Compiler Version 2 with vectorization 
capabilities becomes a powerful tool for 
large-scale scientific and engineering com¬ 
putations. This article illustrates program¬ 
ming techniques necessary for high 
performance on the 3090 and demon¬ 
strates that VS Fortran programs can 
achieve near maximum execution rates. 
The ideas behind these techniques apply to 
other vector processors as well. Implemen¬ 
tation, however, may differ significantly 
depending on machine organization. 

The IBM Engineering and Scientific 
Subroutine Library (ESSL) 1 is a collec¬ 
tion of high-performance mathematical 
subroutines coded primarily in assembly 
language using state-of-the-art algorithms 
tailored to the 3090 Vector Facility. Exe¬ 
cution rates delivered by most ESSL rou¬ 
tines can be nearly equalled by 
programming similarly efficient 
algorithms in Fortran and compiling with 
the VS Fortran Version 2 compiler. 2 

Fortran program efficiency has practi¬ 
cal importance. When Fortran programs 
perform inefficiently, programmers must 
resort to special subroutine libraries or 
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General programming 
techniques for 
hierarchical storage 
management can 
improve 3090 CPU 
performance up to 
three times and 
elapsed time perfor¬ 
mance up to twenty 
times for some vector 
codes. 


assembly language programming for high 
performance. These solutions are not 
completely satisfactory. Efficient subrou¬ 
tine libraries, although useful, lack suffi¬ 
cient flexibility; efficient subroutines to 
perform the desired computation may not 
exist. Assembly language programs 
require too much effort to develop, main¬ 

0018-9162/88/0600-0065$01.00©1988 IEEE 


tain, and modify. Thus, the extent to 
which the execution power of a computer 
is realized for scientific and engineering 
applications often depends on Fortran 
program efficiency and hence the ability of 
the Fortran compiler to generate optimal 
object codes. 

Any attempt to achieve high perfor¬ 
mance on a computer must consider its 
architecture. We review relevant features 
of the 3090 architecture in the next section. 
An optimal program on the 3090 Vector 
Facility must make efficient use of a hier¬ 
archical storage system and take advan¬ 
tage of the compound vector instructions. 
The key programming techniques for 
managing the storage hierarchy are loop 
sectioning, loop distribution, and data 
compaction. The sections “Vector regis¬ 
ter reuse,” “Cache reuse,” and “Virtual 
memory, storage format, and page reuse” 
show how these techniques can lead to effi¬ 
cient use of the vector registers, the high¬ 
speed cache, and the virtual memory sys¬ 
tem, respectively. The compound vector 
instructions are discussed in the section 
“The Multiply-And-Add compound 
instruction.” 

Previous work has developed 3 7 and 
implemented 8 some of these program¬ 
ming techniques and demonstrated their 
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DO 100 J = 1, N 
DO 200 I = 1,N 
A(I,J +1) = B(I) + A(I,J) 
200 CONTINUE 
100 CONTINUE 

(a) 


DO 100 J = 1,N 
DO 200 II = 1, N, M 
do 210 i = 0, MIN(M -1 ,N - II) 
210 vrl(i) = B(II + i) 

do 220 i = 0, MIN(M - 1 ,N - II) 
220 vr2(i) = vrl(i) + A(II + i,J) 

do 230 i = 0, MIN(M - 1,N - II) 
230 A(II + i, J +1) = vr2(i) 

200 CONTINUE 
100 CONTINUE 

(b) 


Figure 1. Example of Fortran code (a) and a representation of compiler-generated 
object code for this example (b). 


DO 1001 = 1,N 
DO 200 J = 1,N 
A(I,J + 1) = B(I) + A(I,J) 
200 CONTINUE 
100 CONTINUE 


(a) 


DO 100 II = 1, N, M 
do 110 i = 0, MIN(M — 1,N —II) 

110 vrl(i) = B(II+i) 

DO 200 J = 1, N 
do 210 i = 0, MIN(M — 1,N — II) 
210 vr2(i) = vrl(i) + A(II + i,J) 

do 220 i = 0, MIN(M - 1 ,N - II) 
220 A(II+ i,J +1) = vr2(i) 

200 CONTINUE 
100 CONTINUE 


(b) 


Figure 2. To achieve vector register reuse, the programmer interchanges the two 
loops of Figure la, as shown in (a). The compiler vectorizes the outer loop and 
generates the object code represented in (b). 


effectiveness for managing data reuse in a 
two-level memory hierarchy. Our work 9 
extends these ideas and applies the pro¬ 
gramming techniques to manage data 
reuse in three or more levels of a memory 
hierarchy. Currently, these techniques 
must be applied manually. However, the 
VS Fortran Version 2 compiler generates 
sufficiently efficient object codes to allow 
effective implementation of all these tech¬ 
niques without resorting to assembly 
language. 


IBM 3090 Vector 
Facility hardware 
characteristics 

The 3090 Vector Facility, an optional 
feature of the 3090 processor, implements 
instructions defined in IBM System/370 
Vector Operations, 10 a compatible exten¬ 
sion to either the IBM System/370 or the 
IBM System/370 Extended Architecture. 
Most new instructions operate on collec¬ 
tions of data, vectors, instead of single 
pieces of data, scalars. 

Vector operands in storage are 
described by the address of the first ele¬ 
ment and the offset, or stride, between 
consecutive elements. The in-storage vec¬ 
tor operands of load and store operations 
can also be described with indirect address¬ 
ing, by a vector containing the arbitrary 
offset of each element from a given 
address, also called gather and scatter. 
Vector instructions operate on a fixed 
maximum number of elements, called the 
section size. Some instructions can oper¬ 
ate on fewer or selected elements of a 
vector. 

The 3090 Vector Facility has a set of 16 
vector registers for 32-bit data, while 64-bit 
data occupy register pairs. Each vector 
register, or pair of registers, may contain 
as many elements as the section size of the 
system, which is 128 for all current models 
of the 3090. 

All 3090 processor systems are imple¬ 
mented using a memory hierarchy. Each 
processor in the system has a small, high¬ 
speed buffer memory, or cache, that can 
satisfy memory accesses without substan¬ 
tial delay. In 3090 systems, each cache con¬ 
tains 64 kilobytes. Information needed to 
execute programs (instructions and data) 
is staged to and from the cache through 
lower levels of the storage hierarchy. These 
levels have a larger capacity but slower 
data delivery rates. They are shared by up 
to six processors in a given 3090 system. 
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The second level in the storage hierar¬ 
chy, the central storage, ranges in size 
from a minimum of 32 megabytes to a 
maximum of 256 megabytes. Larger vir¬ 
tual address spaces can be supported 
through functions provided by the hard¬ 
ware and the operating system that stage 
data from Expanded Storage or from 
magnetic disks. Expanded Storage is an 
optional feature on most models of the 
3090processor system. It can provide from 
64 megabytes to 2,048 megabytes of addi¬ 
tional high-speed storage. 

Vector register reuse 

Reusing the contents of vector registers 
can improve program efficiency by reduc¬ 
ing vector load and store instructions. The 
performance gain can be significant 
because, apart from a small start-up time 
that differs among instructions, vector 
loads and stores require the same execu¬ 
tion time as vector computational instruc¬ 
tions, usually one machine clock-cycle per 
element. Outer-loop vectorization, a 
unique capability of the VS Fortran com¬ 
piler, and loop distribution can be used to 
achieve vector register reuse. 

The potential benefit of outer-loop vec¬ 
torization to promote register reuse is best 
illustrated by example. Consider the For¬ 
tran code in Figure la. 

The Fortran code in Figure lb depicts 
the compiler-generated object code for this 
example. IBM System/370 vector instruc¬ 
tions can have up to three distinct vector 
operands. Some instructions allow one 
vector input operand to be fetched from 
storage concurrently with the execution of 
the operation, but all other operands must 
have been placed in vector or scalar 
floating-point registers. Results of vector 
computations are always placed in 
registers. 

In the code in Figure lb and hereafter, 
each loop represented by a lowercase “do” 
statement denotes one vector instruction. 
Scalar instructions are generally omitted. 
Uppercase variables are fetched from 
memory, vr denotes a vector register and 
A/stands for the vector register section size 
of the processor. 

In the code shown in Figure lb, the loop 
labelled 200 is the vector register section¬ 
ing loop (also known as a blocking, strip¬ 
mining, or chunking loop), which seg¬ 
ments a vector of arbitrary length for the 
finite-length vector registers. Loop 210 is 
a vector load, loop 220 is a vector add from 
storage, and loop 230 denotes a vector 


1 _ 1 


DO 100 J = 1, N/K*K, K 


DO 200 I = l.N 



A(I,J + 1) = B(I) + 

A(I,J) 


A(I,J + 2) = B(I) + 

A(I,J+1) 

200 

A(I,J + K) = B(I) + 

A(I,J + K- 1) 

100 

CONTINUE 



DO 300 J = N/K*K+1, 

N 


DO 4001 = 1, N 



A(I, J + 1) = B(I) + 

A(I,J) 

400 

CONTINUE 


300 

CONTINUE 



Figure 3. The code shown here is an unrolled version of Figure la. 


store. Notice that every iteration of the J 
loop loads vr 1 with each section of B, 
sequentially. There is no vector register 
reuse. The second and following sections 
of M elements of B are loaded into vr 1 
before the first section is needed again. 

VS Fortran’s outer-loop vectorization 
capability provides an easy way to achieve 
vector register reuse. In this example, the 
programmer only needs to interchange the 
two loops in Figure la as shown in Figure 
2a. The compiler vectorizes the outer loop 
and generates the object code shown in 
Figure 2b. The loop selected for vectoriza¬ 
tion, 100, is replaced by the sectioning 
loop. Loop 110 denotes a load to vector 
register vrl, whose contents are used N 
times during the iterations of the / loop. 
The inner loop, 200, now contains only 
two vector instructions, so the code in Fig¬ 
ure 2a executes approximately 30 percent 
faster than the code in Figure la. 

For compilers that do not vectorize 
outer loops, vector register reuse may be 
obtained more laboriously by unrolling an 
outer loop. Loop unrolling 11 replaces 
some iterations of a loop by an explicit 
sequence of statements repeated fewer 
times than the original loop iteration 
count. Most compilers are more capable of 
detecting repeated references to an oper¬ 
and within such an enlarged static 
sequence of statements than in the origi¬ 
nal dynamic sequence. The code in Figure 
la could be unrolled to produce the code 
shown in Figure 3. In loop 200, each sec¬ 


tion of the vector B only needs to be loaded 
once for computing K columns of the A 
matrix. 

You can easily verify that the codes in 
Figures la, lb, 2a, and 2b give the same 
results. In general, vectorization and loop 
interchange can alter the results of a com¬ 
putation because they change the order in 
which operations are performed. For 
example, vectorizing the inner loop in the 
code in Figure 2a, labeled 200, would 
change the results of the computation 
because of data dependence 12 in matrix 
A. In other words, the result of one itera¬ 
tion of a loop is used in a later iteration of 
the same loop. In scalar execution, a new 
value is computed for A(I,2) in the first 
iteration of loop 200 and used in the sec¬ 
ond iteration of the same loop to compute 
A(I,3). In vector execution, the element 
A{1, 3) would be computed by adding B(l) 
to the original value of A(I,2). The VS For¬ 
tran compiler will vectorize a loop only if 
the vector code produces the same results 
as the original scalar code. However, when 
manually interchanging loops, the pro¬ 
grammer must ensure that correct results 
are produced. 

Loop distribution, another technique to 
enhance vector register reuse, partitions 
the statements within a loop among a series 
of loops all at the same level of nesting. 
Each new loop generates the same set of 
values for the induction variable as the 
original loop. 

The code in Figure 4b shows one way of 
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DO 1001 = 1, N 


DO 200 J 

[ = 

= 1, M 





V(I,J) 

= 

B1(I) « 

>C1(I,J) 

+ 

B2(I) - 

■ C2(I,J) 


+ 

B3(I)« 

1 C3(I,J) 

+ 

B4(I) 1 

’ C4(I,J) 

W(I,J) 

= 

Bl(l) - 

1 D1(I,J) 

+ 

B2(I) - 

* D2(I,J) 


+ 

B3(I) - 

' D3(I,J) 

+ 

B4(I) 1 

► D4(I,J) 

X(I,J) 

= 

B5(I)« 

' C5(I,J) 

+ 

B6(I) ’ 

► C6(I,J) 


+ 

B7(l) < 

1 C7(I,J) 

+ 

B8(I) - 

11 C8(I,J) 

Y(I,J) 

= 

B5(I) < 

‘ D5(I,J) 

+ 

B6(I) 1 

► D6(I,J) 


+ 

B7(l) < 

■ D7(I,J) 

+ 

B8(I) < 

* D8(I,J) 


200 CONTINUE 
100 CONTINUE 

(a) 


DO 1001 = 1,N 
DO 200 J = 1,M 

V(I,J) = B1(I) * C1(I,J) + B2(I) * C2(I,J) 

1 + B3(I) * C3(I,J) + B4(I) * C4(I,J) 

W(I,J)= B1(I) * D1(I,J) + B2(I) * D2(I,J) 
1 + B3(I) * D3(I,J) + B4(I) * D4(I,J) 

200 CONTINUE 

DO 300 J = 1, M 

X(I,J) = B5(I) * C5(I,J) + B6(I) * C6(I,J) 

1 + B7(I) * C7(I,J) + B8(I) * C8(I,J) 

Y(I,J) = B5(I) * D5(I,J) + B6(I) * D6(I,J) 

1 + B7(I) * D7(I,J) + B8(I) * D8(I,J) 

300 CONTINUE 
100 CONTINUE 

(b) 


Figure 4. The code in (b) shows one way of distributing loop 200 from the example 
code in (a). 


distributing loop 200 in Figure 4a. As in all 
the examples in this article, we assume 
floating-point variables and arrays to be of 
type REAL *8. As stated above, up to eight 
vector registers are available for REAL *8 
data. The inner loop of code in Figure 4a 
contains references to eight loop constants 
(section-sized vectors of elements from the 
vectors B\, B2,. . . , £8). Only seven vec¬ 
tor register pairs are available to hold these 
loop constants because one register pair 
must be reserved for the result of the com¬ 
putation. The compiler vectorizes the / 
loop and generates 24 vector instructions 
in the inner loop for the code shown in Fig¬ 
ure 4a. Four of these instructions are loads 
for sections of B7 and BS, as they share the 


last available register pair. Only 20 vector 
instructions are generated in the inner 
loops of the code shown in Figure 4b. By 
distributing the J loop into two loops, the 
number of loop constants per loop is 
reduced so that vector register reuse can 
occur. 

Loop distribution is beneficial only if 
the performance gain exceeds the time 
required to execute the additional loop 
control instructions. When manually dis¬ 
tributing loops, you must ensure that the 
correct computation is still being pro¬ 
grammed. 

Automatic outer-loop vectorization is a 
convenient and effective way to maximize 
vector register reuse in nested loops. To 


take advantage of this capability of the VS 
Fortran compiler, programs written for 
compilers without outer-loop vectoriza¬ 
tion capability may need modification. 
Vector register reuse can also be enhanced 
by loop distribution. 


The Multiply-And-Add 
compound instruction 

Optimal programs for the 3090 must 
take full advantage of the fast compound 
vector instructions. Multiply-And-Add 
and Multiply-And-Subtract instructions 
produce more results per cycle than any 
other instructions on the 3090 Vector 
Facility. The Multiply-And-Add instruc¬ 
tion computes a floating-point product 
and a floating-point sum on each clock 
cycle after start-up. Performing the same 
computation with two separate instruc¬ 
tions takes about twice as long. 

Consider matrix multiplication by the 
code shown in Figure 5a. 13 Following 
recommended VS Fortran programming 
style (as detailed in VS Fortran Version 2 
Programming Guide , IBM order number 
SC26-4222-0, p. 158), the result is accumu¬ 
lated in a scalar temporary T. This 
eliminates unnecessary storing of the 
matrix element C(I,J) in the inner loop and 
ensures generation of Multiply-And-Add. 
The generated object code can be repre¬ 
sented by the code in Figure 5b. In the code 
in Figure 5a, the outermost loop is vecto¬ 
rized, maximizing vector register reuse. 
The elements of matrix C are loaded into 
a vector register once and used LK times. 
The innermost loop, DO 300, contains one 
vector instruction, Multiply-And-Add. 

Execution rates of the code in Figure 5a 
for square matrices are compared to 
Engineering and Scientific Subroutine 
Library subroutine DGEMUL, which per¬ 
forms the same computation, in Table 1. 
Fortran execution rates are very close to 
ESSL rates. Performance differences for 
N>80 result from the algorithm used in 
the Fortran code, not from compiler defi¬ 
ciency. An algorithm that better utilizes 
the cache matches the ESSL performance 
for large matrices and is the subject of the 
next section. 


Cache reuse 

Reusing the contents of the cache to 
reduce data transfer between central stor¬ 
age and cache improves execution rate. 


COMPUTER 










Table 1. Execution rate of square 
matrix multiplication on an IBM 3090 
Model 200 VF in millions of floating¬ 
point operations per second. All com¬ 
putations are performed upon REAL*8 
data. The Fortran results are obtained 
using code from Figure 5a and the 
ESSL results obtained using the subrou¬ 
tine DGEMUL. All results are from 
stand-alone runs. 


Dimension 

Fortran 

Mflops 

ESSL 

Mflops 

8 

8.9 

7.7 

16 

20.6 

21.4 

24 

30.1 

32.3 

32 

37.7 

40.6 

40 

44.2 

47.3 

48 

49.4 

52.5 

56 

54.1 

57.3 

64 

57.9 

61.1 

72 

61.1 

63.7 

80 

62.9 

66.0 

88 

62.2 

66.9 

96 

52.6 

69.2 

104 

50.7 

71.4 

112 

51.6 

72.2 

120 

52.6 

73.1 

128 

53.5 

74.6 


DO 1001 = 1, LI 
DO 200 J = 1, LJ 
T = 0.D0 
DO 300 K = 1, LK 
T = T + B(K,J) * A(I,K) 
300 CONTINUE 
C(I,J) = T 
200 CONTINUE 
100 CONTINUE 

(a) 


DO 100 II = 1, LI, M 
DO 200 J = 1, LJ 
do 210 i = 0, MIN(M-1,LI-II) 

210 vrl(i) = 0.D0 

DO 300 K = 1, LK 
srl = B(K,J) 

do 310 i = 0, MIN(M — 1 ,LI — II) 

310 vrl(i) = vrl(i) + srl * A(II + i,K) 

300 CONTINUE 

do 220 i = 0, MIN(M — 1,LI — II) 

220 C(II + i,J) = vrl(i) 

200 CONTINUE 
100 CONTINUE 

(b) 


Figure 5. The result of matrix multiplication by the code in (a) generates the object 
code represented by (b). 


Each 3090 processor, including Vector 
Facility, accesses storage through its own 
64-kilobyte cache. Data are transferred 
between central storage and cache in 
128-byte units, called lines. The storage 
address of the first word in each line is 
divisible by 128. When reference is made 
to data not in cache, there is a delay before 
the referenced line is available. Following 
the delay, data may be transferred at the 
maximum rate of eight bytes per cycle. In 
contrast, references to data in cache can be 
satisfied with negligible overhead at the 
same rate of eight bytes per cycle. 

The cache is four-way set associative. A 
piece of data can only be stored in one of 
four locations within the cache and data 
from addresses separated by multiples of 
16 kilobytes compete for space in the same 
set of four cache lines. The entire cache is 
available for holding contiguous data. For 
noncontiguous data, the effective cache 
size may be much smaller. 


When data is loaded into the cache, the 
least recently used data in the given set of 
four cache lines is displaced. (The cache is 
actually managed with a partitioned least 
recently used policy, but the results are 
identical in a large majority of cases to the 
results of a global least recently used policy 
for each set of four lines. Since we find no 
programming insights in this distinction, 
no further details are of value.) There are 
no instructions that a programmer can 
invoke to explicitly retain data in the 
cache. 

The programming techniques for cache 
reuse are loop sectioning and loop distri¬ 
bution, just as for vector register reuse. 
The technique for ensuring maximum 
utilization of the cache is data compaction 
for contiguous access. 

The need for cache management is illus¬ 
trated by the premature leveling-off of the 
execution rate of the Fortran matrix mul¬ 
tiplication code seen iq the preceding sec¬ 


tion. Consider the code in Figure 5b and 
its data access pattern. Instructions to exe¬ 
cute this program fragment occupy trivial 
space in the cache, as do the various loop 
control and scalar variables. The A matrix 
is the most frequently referenced of the 
three matrices, since it is subscripted by the 
two most rapidly varying indices, i and K. 
Since the cache retains only the most 
recently referenced data and, at any 
instant, most of the recent references will 
have been made to A, the pattern of refer¬ 
ences to elements of A is the dominant 
cache-related factor in determining the 
performance. If LI*LK is small, then A 
can be read into cache once and used 
exhaustively. When LI*LK exceeds the 
effective cache size, A must be loaded into 
cache up to LJ times, each time incurring 
the cost of storage-to-cache transfer. The 
difference between the execution rates of 
the simple Fortran code and ESSL for 
LI=LK> 80 is a reflection of the cost of 
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DO 1001 = 1, LI 
DO 200 J = 1, LJ 
C(I,J) = 0.D0 
200 CONTINUE 
100 CONTINUE 

DO 300 KK = 1, LK, KS 
DO 400 I = 1, LI 
DO 500 J = 1, LJ 
T = C(I,J) 

DO 600 K = KK, MIN(KK + KS - 1,LK) 
T = T + B(K,J) * A(I,K) 

600 CONTINUE 

C(I,J) = T 
500 CONTINUE 
400 CONTINUE 
300 CONTINUE 


Figure 6. Manually sectioning the A"-loop, as shown here, partitions the A matrix 
into submatrices smaller than the effective cache size so that each need be loaded 
into cache only once. This promotes maximum cache reuse. 


this extra storage-to-cache data transfer. 

Maximum cache reuse requires parti¬ 
tioning the A matrix into submatrices 
smaller than the effective cache size so that 
each need be loaded into cache only once. 
This is easily done by manually sectioning 
the K-loop as in the code shown in Figure 
6. If KS*M is less than or equal to the 
effective cache size, the A matrix is loaded 
into cache once as compared to LJ times 
in the code in Figure 5a. The C matrix is 
loaded and stored ceiling(LK/KS) times, 
compared to once in the code in Figure 5a. 
Therefore, one wishes to select the largest 
value for KS that allows cache reuse. 

Computational experimentation is an 
easy way to find the optimal value for KS. 
One method is to determine the execution 
rate of the code in Figure 5a for constant 
LI and LJ as LK is varied. Table 2 shows 
that the execution rate initially increases 
with LK, drops off after Z,AT=48, and 
remains essentially constant at a lower 
level thereafter. 

In this computational experiment, 
effective cache size was determined for an 
A matrix stored contiguously. The effec¬ 
tive cache size for loading the first M rows 
of a larger matrix can be much smaller, 
depending on the number of rows in the 
matrix. We can avoid this problem by 
using data compaction for contiguous 
access, that is, by creating a contiguous, 


temporary copy of each Mx KS submatrix 
of A as needed. 

This technique is illustrated in a pro¬ 
gram fragment for matrix multiplication 
in the next section, “Virtual memory, stor¬ 
age format, and page reuse.” The cost of 
copying is small here, about five percent 
of total execution time, but becomes rela¬ 
tively larger for smaller values of LJ. Table 
3 shows that execution rates of the code in 
Figure 6, with KS = 48 and data compac¬ 
tion, are very close to ESSL rates. 

With a minor modification, the code in 
Figure 6 can illustrate another benefit of 
cache reuse. If the code referenced matrix 
A as A (K, 1) (making the computation per¬ 
form A r *B), the vectors from A would 
have stride equal to the A'-dimension of 
matrix A. Since A is of type REAL*8, 
when the A'-dimension is greater than 15 
each element within a vector of A would 
lie in a different cache line. However, 
other vectors of A would use and reuse the 
data in each of these cache lines such that 
the performance would be essentially iden¬ 
tical to the original code in Figure 6. When 
all the data needed for a computation is in 
cache, performance is independent of 
stride. 

Loop distribution and data compaction 
can enhance cache reuse for loops more 
complicated than the matrix multiplica¬ 
tion example above. Loop distribution, 


described in the section “Vector register 
reuse, ’ ’ can be used similarly to reduce the 
number of arrays that must be kept in 
cache simultaneously for reuse. If a loop 
references many arrays and more than 64 
kilobytes of data, and reuses some data, 
you should consider the possibilities of dis¬ 
tributing the loop. 

Loop distribution may even be useful 
for a loop containing multiple references 
to more than four arrays, regardless of the 
total amount of data accessed. Note that 
loop distribution is not always necessary 
when more than four different arrays are 
referenced in a loop, since arrays that 
together occupy 16 kilobytes or less of con¬ 
tiguous storage do not compete against 
each other for the same locations in the 
cache. Therefore, it can be beneficial to 
arrange for more of the arrays reused in a 
loop to occupy contiguous blocks of stor¬ 
age. If this is not possible, consider the 
technique of data compaction—copying 
the reused arrays into temporary, contig¬ 
uous storage locations and using the copy 
for the computation. Of course, the ben¬ 
efit from reuse must be sufficiently large 
to offset the cost of copying. 

Maximum cache reuse can be achieved 
easily in VS Fortran by explicit loop sec¬ 
tioning, data compaction for contiguous 
access, and loop distribution. A VS For¬ 
tran program for matrix multiplication 
using these techniques, outer loop vectori- 
zation, and the Multiply-And-Add com¬ 
pound instruction executes at nearly the 
same rate as the ESSL subroutine 
DGEMUL. 


Virtual memory, storage 
format, and page reuse 

The 3090 virtual memory system pro¬ 
vides two gigabytes of address space per 
program for both vector and scalar pro¬ 
cessing. Applications with very large stor¬ 
age requirements and favorable data 
access patterns can be run efficiently on 
the 3090. 

The virtual memory architecture is sup¬ 
ported by a three-level memory subsystem 
of central storage (up to 256 megabytes), 
optional expanded storage (up to 2,048 
megabytes), and peripheral memory 
devices such as magnetic disks. Data trans¬ 
fer between levels occurs in units of 4,096 
bytes, or pages. Each page in the address 
space resides in at least one level of the 
storage hierarchy. Reference to data not in 
central storage causes it to be transferred 
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Table 2. Empirical determination of the effective cache size for matrix multiplica¬ 
tion on an IBM 3090 Model 200 VF. Execution rates are given in millions of 
floating-point operations per second. All computations are performed upon 
REAL*8 data. The Fortran results are obtained using code from Figure 5a and the 
ESSL results obtained using the subroutine DGEMUL. All results are from stand¬ 
alone runs. 


Matrix Sizes for Code ii 
LI LJ 

n Figure 5A 

LK 

Fortran 

Mflops 

ESSL 

Mflops 

128 

64 

16 

59.5 

68.7 

128 

64 

32 

67.9 

73.9 

128 

64 

40 

69.7 

74.0 

128 

64 

44 

69.7 

74.5 

128 

64 

46 

69.8 

73.4 

128 

64 

48 

70.2 

74.7 

128 

64 

50 

70.4 

74.6 

128 

64 

52 

69.3 

74.3 

128 

64 

56 

69.0 

73.5 

128 

64 

64 

64.6 

72.6 

128 

64 

72 

56.3 

73.5 

128 

64 

80 

52.4 

74.0 

128 

64 

96 

53.0 

74.5 

128 

64 

112 

53.4 

73.3 

128 

64 

128 

53.7 

74.3 


Table 3. Execution rate of matrix multiplication on an IBM 3090 Model 200 VF in 
millions of floating-point operations per second. The performance of Fortran pro¬ 
grams based on the fragments shown in code from Figure 5a and in code from Fig¬ 
ure 6 are compared to the ESSL subroutine DGEMUL. All results are from 
stand-alone runs. 


Dimension 

Fortran 

Figure 5a 

Mflops 

Fortran 

Figure 6 

Mflops 

ESSL 

Mflops 

512 

53.5 

69.7 

74.3 

1024 

53.7 

69.5 

74.3 

1536 

53.5 

69.6 

74.3 

2048 

53.3 

68.5 

72.6 


from a lower-level memory. If this occurs 
when all central storage allocated to the 
job is in use, then one of the least recently 
used pages is displaced. During page trans¬ 
fer, or paging, the processor does no use¬ 
ful work for the job requesting the page. 
Therefore, data should be structured so 
that a high percentage of the contents of 
a page in central storage is used before it 
is displaced. 

Loop sectioning and loop distribution 
can help minimize paging by using and 
reusing more data in a page between 
replacements. Of course, such considera¬ 
tions are necessary only when a job’s mem¬ 
ory requirement significantly exceeds the 
central storage available to it. These tech¬ 
niques apply to other virtual-memory 
processors and to reducing explicit user 
input and output operations. 

So far, we have considered matrices 
stored in the usual column-major format. 
In the code of Figure 6, matrix A is 
scanned once, B ceiling(LI/ 128) times, and 
C ceiling(LK/4$) times. When L/and LK 
are greater than 512, less than 22 percent 
of an average page of A or C and less than 
nine percent of a typical page of B are used 
in a scan of the matrices. This is unsatis¬ 
factory. When multiplying large matrices, 
the elapsed-time performance of the code 
in Figure 6 is substantially slower than its 
processor-time performance. 

Using a different storage format allevi¬ 
ates this problem. Partition the A and C 
matrices horizontally into submatrices of 
128 rows each and the B matrix horizon¬ 
tally into submatrices of 48 rows each. 
Store the submatrices from each matrix 
one after another, in column-major for¬ 
mat. This storage format is called the 
partitioned-column-major format. Now if 
matrix multiplication is performed using 
the algorithm in the code of Figure 6, full 
page utilization is achieved, leading to a 
significant reduction in paging and hence 
elapsed time. The code using this storage 
format is a straightforward modification 
of the code in Figure 6. 

Efficient use of virtual memory can also 
be achieved without altering the storage 
format. The code in Figure 7 illustrates this 
and data compaction for improved cache 
utilization. Page utilization is improved by 
manually sectioning the /-loop with a sec¬ 
tion size greater than M. If the /-section 
size, IS, is taken to be M= 128 and LI is 
greater than 512, as discussed earlier, an 
average page of A would contain less than 
22 percent useful data. The fraction of use¬ 
ful data per page increases with section size 
IS. For example, for section sizes of 256, 


384, 512, 896, 1,024, and 1,536, the 
amount of data used per page would be 

37.5 percent, 46.8 percent, 50.1 percent, 

65.6 percent, 66.7 percent, and 75.0 per¬ 
cent, respectively. Paging is further 
reduced by sectioning the J loop to pro¬ 
mote reuse of pages in central storage. 

Processor and real-time execution rates 
for matrix multiplication using column- 
major format (CM), partitioned-column- 
major format (PCM), and column-major 
format with sectioning in both I and J 


directions (SCM) are compared in Table 4. 
The SCM code used a section size of 512 
for both / and J loops. Rates are from 
stand-alone runs on a 3090 Model 200 
using only one processor with 32 mega¬ 
bytes of central storage and no expanded 
storage. Central storage available to the 
program is roughly 24 megabytes. Data 
not in central storage were stored in pag¬ 
ing datasets on IBM 3350 magnetic disks. 
We must stress that these data compare 
programming techniques, but do not show 
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C e.g. PARAMETER (IS = 1024, JS = 1024, KS = 48, M = 128 ) 
REAL *8 D(M,KS), T 
DO 100 JJJ = 1, LJ, JS 
DO 200 III = 1, LI, IS 
DO 3001 = III, MIN0(III + IS-1,LI) 

DO 400 J = JJJ, MIN0(JJJ + JS - 1,LJ) 

C(I,J) = 0.D0 
400 CONTINUE 

300 CONTINUE 

DO 500 KK = 1,LK, KS 
DO 600 II = III, MINO(III + IS— 1,LI), M 
DO 700 I = II, MIN0(II + M— 1,111 +IS — 1,LI) 

DO 750 K = KK, MIN0(KK + KS - 1 ,LK) 

750 D(I — II + 1,K — KK+ 1) = A(I,K) 

DO 800 J = JJJ, MIN0(JJJ —JS— 1,LJ) 

T = C(I,J) 

DO 900 K = KK, MIN0(KK + KS — 1,LK) 

T = T + B(K,J) * D(I —11+ 1,K —KK + 1) 

900 CONTINUE 

800 C(I,J) = T 

700 CONTINUE 

600 CONTINUE 

500 CONTINUE 

200 CONTINUE 
100 CONTINUE 


Figure 7. This code illustrates efficient use of virtual memory without alteration of 
the storage format. It also shows data compaction for improved cache utilization. 


Table 4. Execution rate of matrix multiplication on an IBM 3090 Model 200 VF in 
millions of floating-point operations per CPU second and in millions of floating¬ 
point operations per elapsed wall-clock second. The system was configured with 
only 32 megabytes of central storage, no expanded storage, and a suboptimal pag¬ 
ing subsystem for this set of measurements. The performance of Fortran programs 
based on the fragment shown in code from Figure 6 for normal column-major stor¬ 
age (CM), a modified code from Figure 6 for partitioned column-major storage 
(PCM), and the sectioned code from Figure 7 for column-major storage (SCM) is 
given. For the SCM code, both the /-loops and the 7-loops were sectioned at 512, 
which is not an optimal value but still leads to significant performance gains. All 
results are from stand-alone runs. 


Dimension 

CPU 

M flops 

Elapsed 

Mflops 


512 

68.8 

67.1 


1024 

68.9 

58.0 

CM 

1536 

66.0 

6.5 


2048 

* 

* 


512 

69.5 

67.1 


1024 

69.5 

63.2 

PCM 

1536 

69.5 

30.3 


2048 

62.0 

1.9 


512 

69.0 

67.1 


1024 

68.9 

67.1 

SCM 

1536 

69.0 

17.9 


2048 

67.7 

18.9 



the best elapsed-time performance deliv¬ 
ered by a 3090 system with an optimally 
configured paging subsystem. 

Table 4 illustrates the effectiveness of 
loop sectioning in managing virtual mem¬ 
ory. With CM storage format and no loop 
sectioning, paging delays make the elapsed 
time for multiplying larger matrices unac¬ 
ceptably long. PCM storage format 
achieves much better performance. For 
sufficiently large matrices, however, it also 
becomes inefficient. Sectioning both / and 
J loops gives the best performance for 
large matrices. 

Table 5 shows the full performance 
potential of a 3090 Model 200 computer. 
Even for a much larger problem than those 
shown in Table 4, the simple column- 
major code of Figure 6 delivers excellent 
elapsed time performance with 64 mega¬ 
bytes of central storage and 256 megabytes 
of expanded storage. Furthermore, the 
SCM code (shown in Figure 7) gives essen¬ 
tially identical CPU and elapsed time per¬ 
formances. Since the central storage 
available is not sufficient for even one of 
the three matrices in this example, these 
data also demonstrate the performance 
benefits of the expanded storage. 

Section sizes for optimal elapsed time 
performance depend on the data access 
pattern of the code in Figure 7, illustrated 
in Figure 8. The C matrix is partitioned 
into IS x JS blocks and all computation 
involving a block of C is completed before 
work on the next block begins. The blocks 
are processed in block-column-major 
order. Each block is partitioned horizon¬ 
tally into MxJS sub-blocks. The sub¬ 
blocks within each block are scanned from 
top to bottom ceiling(LK/KS) times. If 
IS*JS is sufficiently small that a block of 
C can remain in central storage until the 
calculation involving that block is com¬ 
pleted, then C only has to be loaded into 
central storage once during the calcula¬ 
tion. The number of memory pages needed 
to retain a block of C is 

P-c = (ceiling(IS/ 512) + 1) * JS (1) 

A page holding the bottom elements from 
a column within a block also holds ele¬ 
ments from the following block. Such a 
page can be expected to remain in central 
storage until the computation moves to the 
next block. Thus page fragmentation — 
inefficient usage of pages—can only occur 
at the bottom of each full column of the 
matrix. The number of pages written for 
matrix C is approximately 


72 


COMPUTER 












DO 100 JJJ = 1, LJ, JS 


DO 200 111 = 1, LI, IS 


DO 500 KK = 1,LK, KS 


A (I, K) 


B (K, J) C (I, J) 




KS 


»{nnnnnni 


«<□ 


KS 


DO 600 II = III, MIN(...). M 



JS 


KS ( = 


M 


JS 



Figure 8. A snapshot during an execution of the code in Figure 7, illustrating how the four sectioning loops divide the three 
matrices A, B, and C into small blocks to improve locality of reference. Within loop 500, the ISxJS block of C is sized to fit 
the available central storage. Loop 600 is a redundant vector-register sectioning loop that computes the value of //, used in the 
subscript of the local contiguous matrix D. The four innermost loops implement matrix multiplication of an effective-cache¬ 
sized MxKS block of A by a KSxJS block of B to contribute to an MxJS block of C. This is identical to the computation of 
the code in Figure 6, but for the data compaction of blocks of A into matrix D. 


ft = (ceiling (LI/ 512) + 1 )*LJ (2) 

The B matrix is partitioned vertically 
into LKxJS blocks. Each block is used 
ceiling(LI/IS) times before the next block 
is accessed. Each block is partitioned 
horizontally into KS x JS sub-blocks and 
each sub-block is used ceiting(IS/M) times 
before the next sub-block is processed. 
Since KS is smaller than the length of a 
page, 512 REAL *8 words, a given column 
of a sub-block of B usually lies within one 
page. On average, 

P„~ 1.09 * JS (3) 

pages of central storage would be suffi¬ 
cient to hold a sub-block, allowing B to be 
brought into central storage only ceil- 
ing(LI/IS) times. In a given scan of B, the 
sub-blocks are referenced in a pattern simi¬ 


lar to the pattern described above for C, 
that is, page fragmentation occurs only at 
the bottom of a column. Since each block 
is scanned ceiling(LI/IS) times, the num¬ 
ber of pages fetched for B is approximately 


Q b = ceiling(LI/IS) * 

(ceiling(LK/ 512) + 1 )* LJ (4) 

The A matrix is scanned ceiling(LJ/JS) 
times in the same pattern. In each scan of 


Table 5. Execution rate of matrix multiplication on an IBM 3090 Model 200 VF in 
millions of floating-point operations per CPU second and in millions of floating¬ 
point operations per elapsed wall-clock second. The system was configured with 64 
megabytes of central storage and 256 megabytes of expanded storage for this mea¬ 
surement. The Fortran programs were based on the fragment shown in code from 
Figure 6 for normal column-major storage (CM) and the fragment shown in code 
from Figure 7 for sectioned column-major storage (SCM). All results are from 
stand-alone runs. 


Loop Section Sizes for Code in Figure 7 

CPU 

Elapsed 


Dimension 

IS 

JS 

Mflops 

Mflops 


3072 

_ 

_ 

67.7 

61.7 

CM 

3072 

3072 

1024 

69.4 

68.4 

SCM 


June 1988 
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Table 6. Execution rate of matrix multiplication on an IBM 3090 Model 200 VF in 
millions of floating-point operations per CPU second and in millions of floating¬ 
point operations per elapsed wall-clock second. The system was configured with 
only 32 megabytes of central storage and no expanded storage for this set of mea¬ 
surements. The Fortran program is based on the fragment shown in code from Fig¬ 
ure 7 for normal column-major storage (SCM). All results are from stand-alone 
runs. 


pages are needed to hold elements of A. 
Blocks of A are referenced so that page 
fragmentation occurs at the boundaries of 
each IS X LK block, totaling ceiling(LI/IS) 
times per column. Since the matrix is 
scanned ceiling(LJ/JS) times, approxi¬ 
mately 


Dimension 

IS 

JS 

Sum of 
Scans 

CPU 

Mflops 

Elapsed 

Mflops 


3072 

512 

1536 

8 

68.4 

21.0 


3072 

1024 

1024 

6 

68.7 

25.0 

SCM 

3072 

1536 

1024 

5 

68.9 

27.6 


3072 

3072 

615 

6 

68.9 

25.3 


4096 

512 

1366 

11 

66.8 

20.5 


4096 

1024 

1366 

7 

67.2 

27.2 

SCM 

4096 

2048 

820 

7 

67.3 

27.3 


4096 

4096 

512 

9 

67.3 

23.6 



A, each MxKS block is loaded into cache 
just once and used exhaustively. Since M 
is smaller than the length of a page, 2*KS 
pages of central storage would be suffi¬ 
cient to hold a small block. However, as 
the computation moves from one small 


block of A to another, there must be space 
for both blocks of A to remain in central 
storage to prevent displacing useful but 
less recently referenced pages of B. Thus, 

P a = 4 * KS (5) 


Q a = ceiling(LI/IS) * ceiling(LJ/JS) * 
( ceiling(IS/5l2) + 1 )* LK (6) 

pages are fetched for A during the compu¬ 
tation. 

Section sizes that give optimal elapsed- 
time performance minimize the quantity 

Q- 

Q = Qa + Qb + f* Qc (7) 

where / accounts for the difference 
between paging rates of different devices 
and between average elapsed time for 
reading and writing pages. Because pages 
are loaded into central storage one at a 
time on demand, but written out in groups 
that fill one track on the paging device, 
channel programs used for writing are 
more efficient, consuming less elapsed 
time per page. The value of/should be 1 


-1 
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for reading from disk, and approximately 
0.1 and 0.25 for writing to 3380 and 3350 
disks, respectively. When C is both read 
and written, then / should be approxi¬ 
mately 1.1 or 1.25 for 3380 or 3350 disks, 
respectively. The selected values of IS and 
JS must also meet the constraints: 

N 2: P = P a + P„ + P c (8) 


where TV is the number of pages of central 
storage available to the program. IS 
should be an integral multiple of M to 
maximize the number of vector instruc¬ 
tions executed with full section size. 

Table 6 demonstrates the effects on the 
elapsed-time performance of using 
increasingly larger multiples of 128 as sec¬ 
tion sizes of the /-loop in the SCM code of 
Figure 7. The values for JS were deter¬ 
mined by solving Equations 7 and 8 with 
the chosen value of IS, KS = 48,/= 0.1, 
and N = 6,000 corresponding to the exper¬ 
imental condition of 24 megabytes of cen¬ 
tral storage for the program. We selected 
the values for IS to be integral divisors of 
LI and the calculated values for JS were 
rounded down to be nearly integral divi¬ 
sors of LJ. These choices allow all blocks 


from a given matrix to be the same size. 
The column labelled “sum of scans” gives 
the number of times A and B were 
scanned, that is, ceiling(LI/IS) + ceil- 
ing(LJ/JS). Performance data were 
obtained under the same conditions as in 
Table 4 except that IBM 3380 magnetic 
disks were used for paging. 

Table 6 shows 

(1) Given 24 megabytes of central stor¬ 
age, /S = 512 is too small for optimal 
elapsed-time performance. 

(2) Elapsed-time performance is insen¬ 
sitive to the value of IS if it is near the 
optimal value. 

(3) Sum of scans is a good predictor of 
elapsed-time performance. 

However, sum of scans is only a good 
predictor for square-matrix multiplica¬ 
tion. For rectangular matrices, it should be 
replaced by ceiling(LI / IS) * LK * LJ + 
ceiling(LJ/JS) * LI* LK, or in general by 
the number of pages transferred. 

Note that three 4,096 X 4,096 matrices 
occupy 384 megabytes of memory, which 
is 16 times larger than available central 
storage. The 27 elapsed Mflops achieved 
by the SCM code with 15/16 of the mem¬ 


ory pages on magnetic disks is an impres¬ 
sive demonstration of the power of the 
SCM code and the 3090 computer. 

For application programs with very 
large memory requirements, the applica¬ 
tion of loop distribution and data compac¬ 
tion can also improve elapsed time 
performance. Loop distribution can lead 
to increased reuse of pages and data com¬ 
paction (such as through the partitioned- 
column-major storage layout) can lead to 
improved utilization of pages. 

The matrix multiplication example illus¬ 
trates how the 3090 can be used efficiently 
for applications with large memory 
requirements. While analysis and experi¬ 
ment are needed to establish the data 
access pattern for efficient virtual memory 
usage, the loop-sectioning codes needed 
can be easily and efficiently implemented 
in VS Fortran. 

P rogramming techniques for hier¬ 
archical storage management can 
lead to substantial performance 
gains in scientific and engineering pro¬ 
grams. The potential gain is greatest when 
a program spends most of its time execut¬ 
ing vector instructions and has substantial 
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possibilities for data reuse. Currently, 
many of these techniques must be manu¬ 
ally applied or controlled for a specific 
purpose on a specific machine, but in 
many programs only a few loops need be 
modified to realize nearly all the potential 
performance gain. Nevertheless, it would 
be beneficial to implement these tech¬ 
niques as automatic optimizations in the 
compiler. Research work with various 
source-to-source translators 6,14 has 
addressed most of the theoretical issues 
involved, but no commercially available 
machine-specific, code-generating imple¬ 
mentation of all of these concepts yet 
exists. 

The techniques we have described here 
apply to systems other than the IBM 3090 
VF. Most portable are the techniques for 
managing virtual-memory reuse. Manag¬ 
ing cache reuse may differ substantially in 
detail on systems with different cache 
organizations (such as direct-mapped or 
two-way set-associative). The techniques 
for vector register reuse will become more 
widely applicable as more compilers vec¬ 
torize outer loops. Some currently avail¬ 
able source-to-source translators can 
automatically implement some of these 
techniques and thus produce outer-loop- 
vectorized code through compilers that 
can only vectorize inner loops. Whether 
such outer-loop-vectorized codes will 
achieve vector register reuse depends on 
the optimizing capabilities of the target 
compiler. 

Programming techniques we have advo¬ 
cated here contradict some very general, 
overly simplistic, but commonly believed 
guidelines. Striving to obtain the longest 
possible vector in a vectorized loop will 
likely have a negative effect on perfor¬ 
mance because of a lack of locality of 
reference once the vector is longer than the 
section size of the processor. The “inner¬ 
most loop drives the leftmost subscript” 
rule of thumb, for best scalar performance 
on a processor with a cache, tends to pre¬ 
vent vector register reuse. When outer- 
loop vectorization is possible, a different 
loop nesting may bring substantial perfor¬ 
mance gains. 

The key to high performance from the 
IBM 3090 Vector Facility is proper 
management of the storage hierarchy. In 
this article we have illustrated program¬ 
ming techniques for effectively managing 
the 3090 storage hierarchy and demon¬ 
strated that the VS Fortran Version 2 com¬ 
piler can be used to generate object code 
that executes at near maximum rates in 
both processor time and real time. □ 
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Microprocessors must support more than HLLs 


Two conflicting trends are limiting 
the growth of languages and processors. 
Manufacturers are optimizing micro¬ 
processors for high-level language 
(HLL) support at the expense of other 
important considerations. Meanwhile, 
HLLs are being restricted to match the 
strengths of the underlying processor. 
This circular reasoning must be 
resolved. 

In 1979, Motorola claimed the 68K 
was optimized for Pascal, then the 
“hottest” language. A few years later, 
National Semiconductor said the 32K 
was intended for C, the new “hottest” 
language. The Intel 432 was designed 
from the start for Ada, the “soon-to- 
be-hottest” language. Now, almost all 
processors are optimized for HLLs. 

This tailoring of architectures played an 
important role in microprocessor evolu¬ 
tion toward general-purpose CPUs. 

However, manufacturers systemati¬ 
cally exclude important non-HLL fea¬ 
tures by tailoring architectures toward 
HLL support. With the exception of 
some multiprocessing primitives and 
memory management support, impor¬ 
tant and useful features are ignored or 
discarded as unusable under the 
planned languages. Thus, many proces¬ 
sors are evolutionary in improvement 
instead of revolutionary. 

High-level languages, on the other 
hand, are in many ways limited by CPU 
architecture. Efficient implementation 
of language features such as recursion, 
pointer operations, and bit fields must 
await support from the underlying 
machine. Acceptance of these features 
has always been keyed to efficiency. For 
example, although Pascal was devel¬ 
oped on a CDC Cyber, it is more popu¬ 
lar on non-Cyber computers, which 
better support recursion and many 
other Pascal features. 

Recently, much of the innovation in 
language design has occurred in the 
world of microprocessors. Since these 
CPUs are designed for current HLLs, 
the required CPU features (an impor¬ 
tant component of language evolution) 


have been locked into the status quo. 
This is sad, since one major difficulty in 
implementing large software projects 
such as hosting Unix or developing a 
DBMS is that most programming lan¬ 
guages do not address important new 
(or at least increasingly common) sys¬ 
tem issues such as memory manage¬ 
ment, graphics, and communications. 

As a result, few large software appli¬ 
cations are implemented without 
recourse to facilities outside the stan¬ 
dard language, such as nonstandard 
extensions, another language, assembly 
language, and direct system calls. How¬ 
ever, these are problems that could be 
classified and dealt with more systemat¬ 
ically. 

Although HLLs are used increasingly 
for all purposes, there are notable 
exceptions where the need for total flex¬ 
ibility overwhelms the HLL’s limited 
capabilities. HLLs have simply not kept 
up with industry demands. As a result, 
modularity and extensibility are major 
selling points. More than one powerful 
mainframe DBMS is written in assem¬ 
bly language, as are the TurboDOS and 
OS/9 operating systems. These products 
harness CPU power more directly and 
use the available non-HLL features. 
With more interest in multithreaded 
environments (Mach, OS/2, and 
others), powerful multiple-CPU sys¬ 
tems, and much greater sophistication 
in all system aspects, the gap between 
traditional language facilities and sys¬ 
tem programming requirements will 
continue to grow. 

To close this rift, I propose the fol¬ 
lowing two-step solution: 

(1) Place more emphasis on system 
support when designing the CPU archi¬ 
tecture and specifying the instruction 
set. This does not imply less support for 
HLLs, but rather provision for a hand¬ 
ful of functions to cope with new trends 
in usage and function. 

(2) Provide a consistent approach to 
these features in programming environ¬ 
ments. Form a committee to standardize 
the form of these and future extensions 
for each chosen language. In other 


words, make system evolution a part of 
the language. At worst, many features 
can be expensively simulated in soft¬ 
ware and others can be considered void. 
Thus, we can increase portability by 
providing all mandatory extensions on 
all machines. Many Ada implementa¬ 
tions use this approach. 

I have arbitrarily chosen the follow¬ 
ing areas—operating system support 
and multiprocessor support—simply to 
start the discussion. A standards body 
should decide on the final list(s). 

Operating system support. The oper¬ 
ating system should provide multiple 
supervisor call (SVC) instructions to 
allow modular expansion of system ser¬ 
vices. Some SVCs could be dedicated to 
special functions such as dispatcher and 
file system. Others should be reserved 
for user kernel extensions (such as com¬ 
munications modules, ISAM facilities, 
DBMS kernels, and encryption devices). 
HLLs should allow direct use of these 
features even when their nature is not 
yet known. 

Many operating systems track task- 
related times, such as the amount of 
user and system CPU time expended. 
Although several microprocessors pro¬ 
vide integral task-management facili¬ 
ties, none define these standard and 
easily implemented timing features in 
the CPU. 

Also, although many microprocessors 
support virtual memory, few support 
moving data from one address space to 
another. Consequently, operating sys¬ 
tems that implement virtual machines, 
such as Unix, require special driver rou¬ 
tines to copy memory between the sys¬ 
tem and user address spaces. These 
routines are often large, slow, and com¬ 
plex due to the memory management 
scheme. As a result, some Unix 
machines appear CPU-bound when 
running I/O-intensive jobs. Since most 
microprocessors already support a 
block copy, support for transfers 
between user and system spaces should 
be simple to add. 

Also, a painless method for software 
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to convert a virtual address into a physi¬ 
cal address would help support the next 
generation of peripherals. Sophisticated 
peripheral chips (such as the Am9590 
and some direct memory access con¬ 
trollers) already provide data “gather” 
and “scatter” capability throughout 
memory. This feature allows I/O trans¬ 
fers directly into the user’s virtual 
address space, often eliminating the 
need for the copy operation. Ideally, 
the peripherals would be designed to use 
the system’s memory-descriptor tables. 

In addition, the standards body 
should establish universal definitions of 
“date” and “time” to allow uniform 
operating-system and HLL support. 
How many languages do you know that 
define a “time” or “date” datatype? 


Multiple processor support. Multiple 
processor support is often limited to 
“test and set” primitives along with a 
read/modify/write bus cycle and/or a 
Lock bus signal. While this is sufficient, 
a larger repertoire of facilities would be 
useful. Potential additions include the 
semaphore operations Signal (with 
optional trap to a dispatcher SVC) and 
Wait (with trap to a dispatcher SVC if 
blocked), interlocked linked-list opera¬ 
tions to ease manipulation of global 
lists and tables, and monitors. Such 
additions will become more important 
as multiple-processor and multiple- 
thread operating systems become more 
popular. HLLs should be given these 
data structures and operations in native 
form. 

Other potential areas of improvement 
include memory allocation/deallocation 
primitives, standardized procedure-call 
facilities, and other tasks where a 
slightly modified approach would pro¬ 
vide increased functionality. I am not, 
however, simply proposing increased 
microprocessor or instruction set com¬ 
plexity. In fact, many of these features 
would be as applicable on RISC proces¬ 
sors as on CISC processors. On the 
other hand, I am not arguing that these 
features simply be supported by enlarged 
subroutine libraries. The suggestions 
here would add little to the cost of man¬ 
ufacturing and development yet would 
pay off handsomely in product longevity. 

The trend toward microprocessors 
more directly supporting HLLs will 
continue for the foreseeable future. 

This is generally good. However, over¬ 
all system functionality will be 
enhanced if system architecture and 
development environments provide for 
current and future changes. 

Robert Cousins 

Commercial Systems 


For the past two years we have 
applied object-oriented programming 
techniques to both our research and 
teaching at the undergraduate and 
graduate levels. During this time we 
have asked ourselves many stylistic 
questions such as: When is an object- 
oriented program written in “good” 
style? Is there some formula or rule one 
can follow to write good object-oriented 
programs? What metrics can we apply 
to an object-oriented program to deter¬ 
mine if it is good? What are the charac¬ 
teristics of good object-oriented 
programs? 

We believe two simple guidelines— 
now known in-house as the Law of 
Demeter—answer these questions and 
help to formalize existing ideas. 1 ' 3 
Demeter 4 is the name of an object- 
oriented programming environment 
developed at Northeastern University. 
The explanations and examples below 
are written in Demeter notation, a 
modified EBNF notation. 5 

One of the primary goals of the 
Demeter system is to develop an envi¬ 
ronment that facilitates the evolution of 
a class hierarchy. Such an environment 
must provide tools for the easy updat¬ 
ing of existing software (that is, the 
methods or operations that are defined 
on the class hierarchy). We are striving 
to produce an environment that will 
allow software to be “grown” in a con¬ 
tinuous fashion rather than in sporadic 
jumps that undoubtedly lead to major 
rewrites. This is in alignment with the 
fast prototyping and updating system- 
development cycle that is becoming 
common in the artificial intelligence 
community. 

To achieve this flexibility, we would 
like the programs to be “well 
behaved.” In other words, the pro¬ 
grams should follow a certain style that 
enables them to be modified easily. This 
ease of modification is one criterion 
that characterizes a good object- 
oriented programming style. 

Ease of modification should be 
adopted by all programmers who use 
object-oriented programming tech¬ 
niques. To write easily maintainable 
systems, every object-oriented program¬ 
mer should also know what is consid¬ 
ered good object-oriented programming 
style Gust as procedural programmers 
are aware of the top-down program¬ 
ming paradigm, the “thou shalt not use 
a goto” rule, and others). 6 Even though 
a programmer using a nontyped object- 
oriented system will not be able to fol¬ 
low the “letter of the Law”—since the 
Law of Demeter is written in terms of 


types—he or she will be able to adhere 
to its spirit. 

We challenge object-oriented 
programmers to check whether their 
programs follow our law and, where 
they do not, to consider whether they 
should. We welcome any comments or 
examples that require a contradiction to 
the Law of Demeter. 

Notation. The class hierarchy in 
Demeter is described using three types 
of production rules: 

(1) A construction production is used 
to build a class from a number of other 
classes and is of the form C = (id]) 

SCi . . . (id„) SC n . Here Cis defined as 
being made up of n parts called instance 
variables. Each part has an identifier 
(id,) and a type SC, (called an instance 
variable type). This means that for any 
instance (or member) of C the identifier 
idj refers to an instance of class SC,. 

The following example describes a 
library class as consisting of a reference 
section, a loan section, and a journal 
section. 

Library = (reference) Reference-Sec 
(loan) Loan-Sec 
(journal) Journal-Sec. 

(2) An alternation production allows 
us to express objects that define union 
types. A production of the form C : 

A | B. states that a member of C is a 
member of class A or class B (exclu¬ 
sively). For example, 

Book-Identifier : ISBN | 
Library-of-Congress. 

expresses the notion that, when we refer 
to the identifier of a book, we are actu¬ 
ally referring to its ISBN code or its 
Library of Congress code. 

(3) A repetition production is simply 
a variation of the construction produc¬ 
tion where all instance variables have 
the same type and the number of 
instance variables is not specified. The 
production C~{A} defines members of 
C as lists of zero or more instances of 
A. 

We partially define a reference sec¬ 
tion in the library class in the following 
class dictionary: 

Reference-Books-Sec = 

(ref-books) List-of-Books 
(ref-catalog) Catalog. 

List-of-Books ~ {Book}. 

Catalog ~ {Catalog-Entry}. 
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Book = <title) String 

(author) String <id) Book- 
identifier. 

To express inheritance we use the 
notation *inherit* with a construction 
production. For example, every 
mathematics text book is a member of 
the class Book (as defined above), but it 
has some additional characteristics. We 
can express this by 

Math-Text = <math-cat) Math- 
Category inherit* 
Book. 

Math-Category : Algebra | Calculus | 
Statistics. 

An instance of Math-Text is also a mem¬ 
ber of Book and will therefore contain 
the instance variables of both. We use 
class and type as synonyms. 

The Law and Demeter. In any 

method M attached to a class C, only 
messages to self and objects that are 
instances of, and not only members of, 
the following types are allowed: 

(1) the instance variable types of C 
and 

(2) the types of the arguments of M. 
Any global objects or objects created in 
M are considered arguments to M. 

This law has two primary purposes: 

(1) It simplifies the updating of a pro¬ 
gram when the class dictionary is 
changed. 

(2) It simplifies the complexity of 
programming by restricting the number 
of types the programmer has to be 
aware of when writing a method. 

The Law of Demeter enforces good 
programming style when used in coordi¬ 
nation with two key constraints. These 
constraints require minimizing code 
duplication and the number of argu¬ 
ments passed to methods. 

Motivation and explanation. This law 
ensures that software is as modular as 
possible. Any method written to obey 
this law will only know about the 
immediate structure of the class to 
which it is attached. The structure of 
the arguments and the substructure of C 
are hidden from M. Therefore, if a 
change to the structure of the class C is 
necessary, we need only look to those 
methods attached to C for possible con¬ 
flicts. The law effectively reduces the 
occurrences of nested message sending 
and simplifies the methods. 

The Law of Demeter is related to the 
fundamental thesis of denotational 
semantics. That is, “he meaning of a 
phrase is a function of the meanings of 


its immediate constituents. This goes 
back to Frege’s work on the principle of 
compositionality. 7 

For example, we can expand the 
Library definition above into a nearly 
complete class dictionary: 

Library = (reference) Reference-Sec 
(loan) Loan-Sec 
(journal) Journal-Sec. 

Reference-Sec = 

(ref-book-sec) Books-Sec 
(archive) Archive. 

Archive = 

(arch-microfiche > 

Microfiche-Files 
(arch-docs) Documents. 

Microfiche-Files = 

(micro-list) List-of-Microfiche 
(micro-cat) Microfiche-Catalog. 

Books-Sec = (books) List-of-Books 
(book-catalog) Catalog. 

List-of-Books ~ {book}. 

Catalog ~ {Catalog-Entry}. 

Book = < title > String 
< author > String <id> 
Book-Identifier 

Book-Identifier : ISBN | 
Library-of-Congress 

Suppose we wish to attach a method 
to the Library class that will search its 
reference section for a specific book: 

(defmethod (Library : Ref-Search) 
(book :type Book-Identifier) 

(send reference : Ref-search 
book)) 

The Library class simply passes the 
message to its Reference-Sec: 

(defmethod (Reference-Sec :Ref- 
search) 

(book :type Book-Identifier) 

(or (send ref-book-sec 
:search book) 

(**) (send (send archive 

: arch-microfiche) 
:search book) 

(**) (send (send archive 
: arch-docs) 

: search book))) 

(defmethod (Microfiche-Files: search) 
(book :type Book-Identifier) 

. ) 

(defmethod (Documents :search) 
(book :type Book-Identifier) 

. ) 

(defmethod (Books-Sec :search) 

(book :type Book-Identifier) 

. ) 

The Ref-search method attached to 
Reference-Sec passes the message to its 
book, microfiche, and document sec¬ 
tions. As written above, this method 
breaks the Law of Demeter. The first 
message marked (**) sends the message 
arch-microfiche to archive, which 
returns an object of type Microfiche- 
Files. This method next sends this 


returned object the search message. 
However, Microfiche-Files is not an 
instance variable or argument type of 
class Reference-Sec. Since the structure 
of all the classes is clearly defined by 
the class dictionary, we might be 
tempted to accept the above methods as 
a reasonable solution. 

Let us consider a change to the class 
dictionary. Assume the library installs 
new technology and replaces the micro¬ 
fiche and document sections of the 
archive with CD-ROMs or video disks. 

Archive = 

(cd-rom-arch) CD-ROM-File. 

CD-ROM-File = 

(cd-c-system) Computer-system 
(discs) CD-ROM-Discs. 

We now have to search all of the 
methods, including the Ref-search 
method, for references to an archive 
with microfiche files. It would be easier 
to contain the modifications only to 
those methods that are attached to 
archive. We accomplish this by rewrit¬ 
ing the methods in good style. 

(defmethod (Reference-Sec : Ref- 
Search) 

(book :type Book-Identifier) 

(or (send ref-book-sec :search 
book) 

(send archive: search 
book))) 

(defmethod (Archive : search) 

(book :type Book-Identifier) 

(or (send arch-microfiche 
: search) 

(send arch-docs: search))) 

The trade-off. Writing programs that 
follow the Law of Demeter decreases 
the frequency of nested-message send¬ 
ing and the complexity of the methods, 
but it increases the number of methods. 
It might also increase the number of 
arguments passed to some methods. 
However, the increased number of 
methods need not affect performance, 
since the methods can be implemented 
via in-line expansion in many lan¬ 
guages. 

A problem. Suppose we want to send 
a message to a reference section that is 
to return its book catalog. The method 
definition might look like: 

(defmethod (Reference-Sec :return- 
book-cat)() 

(send ref-book-sec :book-catalog)) 

This method appears to obey the Law 
of Demeter, since we are sending a mes¬ 
sage to an instance variable type of 
Reference-Sec. However, the message is 
the name of an instance variable that is 
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not a part of Reference-Sec. This cre¬ 
ates a situation in which the above 
method is sensitive to changes within 
the structure of the Book-Sec class. This 
clearly violates the spirit of the law. The 
solution to this problem is to rewrite the 
methods as follows: 

(defmethod (Reference-Sec :return- 
book-cat)() 

(send ref-book-sec :return- 
book-cat)) 

* (defmethod (Book-sec :return- 
book-cat)() 

(send-self :book-catalog)) 

We must be careful not to reduce the 
readability of a program with too many 
small methods, such as the one marked 
with an asterisk. 

Feedback. We have verified the Law 
of Demeter experimentally and theoreti¬ 
cally. In our experimental work we have 
checked that our object-oriented programs 
—including the Demeter system—can 
be translated to good style. We have 
proved theoretically that any programs 
written in bad style can be transformed 
efficiently into programs that follow the 
Law of Demeter. 

We claim that all object-oriented pro¬ 
grams should follow our objective sense 
of style. A more detailed version of this 
article is available from the authors 
upon request. If you don’t agree with 
our argument, please send a program 
that justifies the breaking of our rules 
to holland @corwin .ccs. northeastern. edu 
Karl Lieberherr, 
lan Holland, 

Gar-lin Lee, and 
Arthur J. Riel 
Northeastern University 
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Editor: Helen M. Wood, National Bureau of Standards, B154 Technology, Gaithersburg, MD 20899; (301) 975-3240 


US government moves toward implementing OSI standards 

Shirley M. Radack, National Bureau of Standards 


After a 10-year effort supporting 
open systems interconnection (OSI) 
standards, the US government is mov¬ 
ing ahead to implement the concept. 

The vehicle for the government’s 
action is the Government Open Systems 
Interconnection Profile (GOSIP), a 
specification that is compatible with 
industry specifications for OSI. This 
move is expected to push the demand 
for OSI standards-conforming 
products. 

The government expects to complete 
its Federal Information Processing 
Standard (FIPS) for GOSIP before the 
end of July. Based on national and 
international standards for OSI, GOSIP 
will enable US governmental agencies to 
start planning for and acquiring the 
technology that will make it possible to 
communicate information between 
computers manufactured by different 
vendors. 

GOSIP and its underlying technical 
agreements are the result of activities 
the National Bureau of Standards 
initiated in the late 1970s. That’s when 
the NBS Institute for Computer 
Sciences and Technology (1CST), the 
agency responsible for developing com¬ 
puter and related telecommunications 
standards for the federal government, 
began a long-term effort to foster devel¬ 
opment of the standards needed for 
government networking activities for 
the remainder of this century. 

The efforts are now coming to fru¬ 
ition and, when they do, GOSIP is 
expected to be an important tool for the 
government’s use of networks to 
improve information exchange and pro¬ 
ductivity. 

With the increased use of computers 
for a variety of information-processing 
tasks, government users cannot satisfy 
all their computing requirements with a 
single vendor’s products. They need to 
integrate and transfer information 
between the systems of different 
manufacturers in a multivendor envi¬ 
ronment and must be able to add to 
existing systems in a modular fashion. 
Standards are important technical and 


management tools for achieving these 
objectives in a cost-effective way. 

This approach encouraged standards 
that would meet the needs of both 
industry and government. 

NBS workshops. In 1983, it became 
clear that the completion of OSI stan¬ 
dards would not be sufficient to achieve 
interoperability goals. The standards 
that were developed included options, 
classes, and subsets that could be imple¬ 
mented in different ways, with resulting 
incompatibilities. 

With the support of industry, NBS 
organized a workshop series for OSI 
implementors. In these open interna¬ 
tional forums, participants agreed on 
implementing options, classes, and sub¬ 
sets so that products based on the stan¬ 
dards will be interoperable. 

GOSIP is based on the agreements 
developed at the workshops. Industry 
groups developing similar profiles, such 
as the Manufacturing Automation Pro¬ 
tocol (MAP) and the Technical and 
Office Protocol (TOP), also use the 
workshop agreements as the basis for 
their specifications. Similarly, the con¬ 
formance tests being developed by the 
Corporation for Open Systems (COS) 
are based on workshop agreements. 

Agreements developed by the NBS 
Workshop for Implementors of OSI 
were used for the 1984-1987 demonstra¬ 
tions of OSI protocols. The first full set 
of planned GOSIP-conforming 
products will be demonstrated at the 
1988 International Enterprise Networking 
Event June 6-8 in Baltimore, Maryland. 

The workshop results have been 
documented in a series of publications 
detailing the agreements. After five 
years of activity, the agreements were 
divided into a stable set and a set under 
development. The stable set was issued 
in December 1987 as NBS Special Publi¬ 
cation 500-150, Stable Agreements for 
Open Systems Interconnection Protocols. 

GOSIP implementation. GOSIP was 
announced as a proposed FIPS in 
October 1987 and is now undergoing 


final review. The document includes the 
technical details necessary to specify 
exactly what a vendor must provide for 
an agency network acquisition. 

The FIPS may be used immediately 
by agencies ready to proceed with 
acquisition of OSI networks, but it 
establishes a two-year transition period 
before federal-government use of the 
FIPS becomes mandatory. This transi¬ 
tion period enables vendors to develop 
products that meet the specifications 
and enables users to plan for the imple¬ 
mentation of OSI. 

Initially, GOSIP defines a set of pro¬ 
tocols to support file transfer, access, 
management, and electronic mail appli¬ 
cations over existing standard network¬ 
ing technologies. The relevant existing 
standards are IEEE Iocal-area-network 
standards 802.3, 802.4, and 802.5, plus 
the International Consultative Commit¬ 
tee for Telegraphy and Telephony 
(CCITT) recommendation X.25 for the 
public data network interface. 

Additional protocols, networking 
technologies, and functionality will be 
added as the international standards 
and the implementing workshop agree¬ 
ments are developed. 

At most, revisions to GOSIP will be 
made once a year. The initial version 
defines a minimally useful set of appli¬ 
cations and other services. Additions 
will be made to increase the func¬ 
tionality. 

Future near-term additions are 
expected to include protocols for 
remote terminal access, office docu¬ 
ment interchange, and directory ser¬ 
vices. Other applications that may be 
added later are electronic exchange of 
business forms, and graphics data. 

New network services will be added, 
including connection-oriented network 
service for operation over single net¬ 
works. Expected additions for transac¬ 
tion processing, Integrated Services 
Digital Network (ISDN), and the fiber 
distributed data interface (FDDI) lie 
further in the future. 

Upward compatibility will be main¬ 
tained when new functions are added to 
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GOSIP. As each new function is added, 
a transition period will be provided for 
implementors and users to plan for 
future products. 

Additions weighed. Other planned 
additions to GOSIP are also being con¬ 
sidered. Three important areas under 
development include dynamic routing, 
network management, and network 
security. 

The first version of GOSIP only 
includes provisions for static routing. 
While this is acceptable for many appli¬ 
cations, static routing does not meet the 
needs of advanced users such as the US 
Department of Defense. 

In the next version of GOSIP, provi¬ 
sion will be made for host and network 
routers to work together. Later, 
dynamic routing will be possible among 
network routers administered by a sin¬ 
gle organization. Later still, dynamic 
routing will be possible between 
separately administered routine domains. 

The requirement for network 
management will be critical. Although 
voluntary industry standards are 
unlikely until the early 1990s for net¬ 
work management and even later for 
products, some interim solutions may 
be available within the next year or two. 
For example, the MAP 3.0 specification 
contains some network management 
capabilities that might be considered for 
use in the period before standards are 
final and standards-conforming 
products are available. 

Perhaps even more critical is the 
requirement for network security. Here, 
requirements must be met for protect¬ 
ing both classified and unclassified 
information. Work is underway within 
several federal government organiza¬ 
tions to create a suitable architecture 
and specific protocols that will allow 
for appropriate OSI security. 

In its current form, GOSIP will ena¬ 
ble users to achieve interoperability of 
standard applications operating over 
standard network technologies. 

Added advantages. While the benefits 
of interoperability are significant for 
users, GOSIP will also provide other 
benefits. The standard internetwork 
and transport protocols specified in 
GOSIP will allow users to interconnect 
non-standard network technologies and 
will provide end-to-end service reliability. 

The Department of Defense is taking 
the lead in requiring GOSIP in future 
network acquisitions. In 1987, the DoD 
issued a policy statement outlining the 
shift from the current department pro¬ 
tocol set (TCP/IP) to OSI. 

For a two-year period, the TCP/IP 
and OSI protocols will be co-standards. 


After two years, OSI protocols will be 
used in acquisitions. The transition will 
be eased by using gateways between the 
two protocol suites. 

This DoD policy recognizes that there 
are significant advantages in using com¬ 
mercial vendor products if they meet 
the department’s operational needs. 
These advantages are 

• lower costs because of a broader mar¬ 
ket for vendor products and 
improved competition, 

• more effective products integrating 
protocol functions across product 
lines, and 

• better use of scarce management and 
technical resources by the organi¬ 
zation. 

Using a complex specification such as 
GOSIP raises issues of conformance 
and interoperability testing. Several 
testing organizations are developing 
conformance tests and test systems. 
ICST will specify which tests, test sys¬ 
tems, and testing organizations are cer¬ 
tified for GOSIP protocols. 

Interoperability testing may also be 


Standards Briefs 

Industry, NBS complete conformance 
test for Posix. Representatives of US 
industry and the National Bureau of 
Standards Institute for Computer 
Sciences and Technology have devel¬ 
oped a test suite to evaluate confor¬ 
mance of operating systems to the 
proposed federal standard entitled Port¬ 
able Operating System Interface for 
Computer Environments. Known as 
Posix, the standard was developed by 
the Computer Society’s Technical Com¬ 
mittee on Operating Systems. 

Posix defines the interface—or 
link—between applications and AT&T’s 
Unix technology. This technology is 
rapidly gaining acceptance as the cor¬ 
nerstone for an open-systems architec¬ 
ture to facilitate moving software from 
one computer environment to another. 

AT&T, Digital Equipment, Hewlett- 
Packard, IBM, Perennial, and a con¬ 
sortium of 13 vendors called X/Open 
contributed to development of the test 
package. 

Posix is expected to be approved soon 
as an interim Federal Information Pro¬ 
cessing Standard (FIPS) developed by 
the NBS for use by the federal 
government. 

For ordering information on the con¬ 
formance test package, contact the NBS 


desirable considering the complexity of 
GOSIP implementations. ICST may 
also recommend tests suitable for 
interoperability testing. 

The development of GOSIP points 
up the need for overall organizational 
planning to overcome incompatible net¬ 
works that may have developed over the 
years. OSI standards can be imple¬ 
mented in compatible, interoperable 
products. The planning for them should 
be done in a systematic way across 
operating units within an organization. 

Incompatible computers and net¬ 
works present a growing problem 
within many government organizations. 
GOSIP provides an opportunity for 
organizations to establish control over 
their network resources. 

The work of the federal government 
and the private sector to advance the 
implementation of OSI standards in 
products can help to overcome the 
problems of non-communicating appli¬ 
cations. By planning now for OSI use, 
users can take steps to improve infor¬ 
mation exchange in the future. 


Systems and Software Technology Divi¬ 
sion, Rm. B266, Technology Bldg., 
NBS, Gaithersburg, MD 20899, phone 
(301) 975-3295. 

US, UK, Canada working on office 
exchange test. Researchers at the NBS 
in the US, the National Computing 
Center in the United Kingdom, and the 
Department of Communications in 
Canada are collaborating on a testing 
method and tools for a newly adopted 
international standard related to for¬ 
matting office documents. 

The standard will make it possible to 
revise, process, and exchange office 
documents across different manufac¬ 
turers’ systems without reformatting. A 
test method is needed to determine 
whether the standard is implemented 
properly in a particular product. 

The NBS was involved in developing 
the international standard, called the 
Office Document Architecture and 
Interchange Standard (International 
Organization for Standardization 8613), 
and plans to propose it as a FIPS. 

For further information, contact the 
Systems and Software Technology Divi¬ 
sion, NBS, Rm. B266, Technology 
Bldg., Gaithersburg, MD 20899, phone 
(301) 975-3344. 


June 1988 


83 



C °S NEWS 


Editor: Sallie Sheppard, Office of Associate Provost for Honors Program and Undergraduate Studies, Texas A&M University, College Station, TX 77843; (409) 845-3210 


Hamming, Kirchmayer, 

Four Computer Society members, 
Richard W. Hamming, Leon K. Kirch¬ 
mayer, Karl E. Martersteck, Jr., and 
Merlin G. Smith, were honored at the 
1988 IEEE Medals Presentation 
ceremony May 9 in Boston. 

Hamming, adjunct professor of com¬ 
puter science at the Naval Postgraduate 
School in Monterey, California, 
received an award that bears his name, 
the Richard W. Hamming Medal. It 
was presented for the first time for 
“exceptional and pioneering contribu¬ 
tions to information science and sys¬ 
tems, and for inspiring generations of 
researchers in these fields.” 

Kirchmayer was the recipient of the 
1988 Lamme Medal for his “pioneering 
work in the operation and planning of 
electric utility systems.” Kirchmayer, 
who served in various engineering 
management positions with General 
Electric for 36 years, retired in 1984 
after seven years as manager of 
advanced system technology and 
planning. 

Martersteck, executive director of the 
Digital Switching Systems Division of 
AT&T Bell Laboratories in Naperville, 
Illinois, received the first Medal for 
Engineering Excellence for his contribu¬ 
tions to development of digital telecom¬ 
munication switching systems and the 
5ESS switch in particular. 

Smith, program manager for systems 
applications in the Advanced Silicon 
Technical Laboratory at the IBM T.J. 
Watson Research Center in Yorktown 
Heights, New York, won the first-ever 
Richard M. Emberson Award for 
“important contributions and dedicated 
service” to the IEEE’s technical 
programs. 

Hamming was the first to demon¬ 
strate that digital system errors could be 
easily corrected when he introduced 
error-correcting codes. These codes 
automatically correct errors in the inter¬ 
nal workings of a machine as long as 
the number of errors is below a certain 
level. 

This contribution to information the¬ 
ory had a dramatic impact on the field 
and led to a proliferation of solutions 
for automatic correction of computer 
errors. Hamming has played a central 


Martersteck, Smith earn high IEEE awards 



Richard W. Hamming (top left), Leon K. Kirchmayer (top right), Karl E. Marter¬ 
steck, Jr. (bottom left), and Merlin G. Smith (bottom right) were honored at the 
1988 IEEE Medals Presentation in Boston May 9. 


role in developing computer science and 
is an acknowledged pioneer in such 
areas as digital filters and computer- 
aided design of electronic circuits and 
systems. 

The Hamming Window, the simplest 
of many data-smoothing processing 
schemes, was named in his honor. 

Hamming was a charter recipient of 
CS Computer Pioneer Award, also 
presented in recognition of his work on 
error-correcting codes. In addition, he 
previously won the IEEE Emanuel E. 


Piore Award, is a Fellow of the IEEE, 
and is a member of the National 
Academy of Engineering. 

The Lamme Medal presented to 
Kirchmayer is supported by the Wes- 
tinghouse Foundation. Established in 
1928, it is awarded for “meritorious 
achievement in the development of elec¬ 
trical or electronic apparatus or systems. ’ ’ 

While a member of the network anal¬ 
ysis research team at GE in Schenec¬ 
tady, New York, Kirchmayer was 
primarily responsible for developing 
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With an eye toward the 1990s, TAB 
launches cross-TC activities 


key computer programs used to regulate 
the generation and transmission of elec¬ 
tric power. 

His computer simulations and the 
underlying mathematical theory are 
widely used in the study and operation 
of the interconnected networks of 
generating stations and transmission 
lines that link most electric utility com¬ 
panies in the United States. By effi¬ 
ciently regulating these networks, 
electrical utilities manage to have the 
right amount of electricity at the right 
place at the right time. 

Kirchmayer is an IEEE Fellow. 

The award to Martersteck was devel¬ 
oped to recognize exceptional achievement 
in the application of electrotechnology 
for the benefit of both the public and 
the engineering profession. 

As an engineering manager at AT&T 
Bell Labs, Martersteck oversaw devel¬ 
opment work on two digital electronic 
switching systems—AT&T’s 4ESS toll 
switch and 5ESS local-and-toll switch. 
Located at AT&T and other telephone 
company central offices worldwide, 
these switches use advanced microelec¬ 
tronics and software technologies to 
reroute calls to their destinations. 

Introduced in 1982, the 5ESS switch 
is a cornerstone of the emerging Inte¬ 
grated Services Digital Network, han¬ 
dling voice, data, and image traffic as 
well as providing operator services. The 
20 millionth 5ESS switch customer line 
went into service this April. 

Martersteck is a senior member of the 
IEEE. 

Active in the IEEE for over four 
decades, Smith has held a number of 
important Computer Society posts, 
including president in 1977-78, director 
of Division VIII in 1983-84, executive 
vice president in 1985, and vice presi¬ 
dent for technical activities in 1986. He 
is currently CS vice president for mem¬ 
bership and information and chair of 
the IEEE Membership Development 
Committee. 

An IEEE Fellow, Smith is a past 
recipient of the IEEE Centennial Medal 
and the CS Richard E. Merwin Distin¬ 
guished Service Award. 

Smith has been with IBM since 1952 
and participated in the early develop¬ 
ment of electronic computers. He 
served as engineering manager for 
large-scale integration before assuming 
his current post. 

The award Smith received was named 
in honor of a man who was one of the 
IEEE’s most prominent leaders until he 
died in 1985. Emberson served as the 
staff executive in charge of technical 
activities as well as executive director 
and general manager during his 23 years 
of institute involvement. 


Laurel V. Kaleda, TAB Chair 

The Computer Society’s Technical 
Activities Board has initiated a number 
of major inter-technical committee 
activities this year, including a reassess¬ 
ment of technical committee member¬ 
ship policies directed toward developing 
a plan to strengthen both the TAB and 
the 33 TCs. The idea is to create an 
improved base to support increased 
membership activities and benefits in 
the 1990s. 

Another cross-TC effort entails con¬ 
ducting an Interdisciplinary Satellite 
Symposium (ISS) sponsored by eight of 
the TCs and covering a number of tech¬ 
nical areas of interest to our members. 

Still another relates to formation of 
task forces dealing with professional 
tools, global change, and neural 
networks. 

Self-assessment. These inter-TC 
activities are the outgrowth of a very 
thorough self-assessment TAB con¬ 
ducted at the end of 1987. The sum¬ 
mary of this self-examination was 
presented to the TAB and the society’s 
Board of Governors last October. 

As is normal for any complex organi¬ 
zation, the results contained both good 
and bad findings. Included in the good 
news was the general health and growth 
of specific TC activities. Amid the bad 
news was the problem that very few of 
the society’s members knew about the 
TCs and their role as sponsors of all 
technically related society activities. 

The TCs, plus several interdiscipli¬ 


nary task forces, form the organiza¬ 
tional structure of the TAB through 
which all activities are managed. Each 
TC and task force concentrates on a 
particular technical specialty area, 
enhancing the focus of society mem¬ 
bers’ interest in that area. 

Membership. An ad hoc committee 
led by TAB Vice Chair Mario Barbacci 
has been given the responsibility of 
defining the TC membership plan and 
proposing a scenario for its implemen¬ 
tation. The committee’s ultimate goal is 
to structure a membership plan that will 
encourage more direct volunteer partici¬ 
pation in TC activities and increase the 
general member’s awareness of the TCs 
and their activities. 

The committee members will evaluate 
the ground rules for TC membership 
and the implications of various policy 
changes in the way TC membership is 
structured. They will be assessing 
“What makes a TC vital?” and “When 
should a TC be considered dormant?” 

A report on the committee’s work will 
be given at the June 15 TAB meeting in 
Anaheim, California. 

Satellite symposium. The ISS effort is 
being led by Paul Hazan, with the sup¬ 
port of Ken Anderson, CS president¬ 
elect and TAB past-chair. Funding has 
been established for this project, and 
plans are well-formed on the content of 
the symposium. 

The TCs on design automation, 


Survey conducted to determine 
future of Microprogramming TC 

Volunteer participation in activities of the Technical Committee on 
Microprogramming has seriously declined over the past few years. Unless 
significant interest and support for microprogramming activities is shown 
during a current survey, the Technical Activities Board will recommend to 
the CS Board of Governors that the TC be discontinued. 

A letter was sent to all members of the Microprogramming TC in April 
to obtain the answers to two questions: 

(1) How many TC members are interested in continuing the activities 
of the TC on Microprogramming? 

(2) Are any TC members willing to participate actively in Micropro¬ 
gramming TC activities? 

By June 30, CS members interested in the technical area of micropro¬ 
gramming are asked to call Dave Barber at the society’s Washington, DC, 
office at (202) 371-0101 to advise him of their interest. 
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office automation, pattern analysis and 
machine intelligence, personal comput¬ 
ing, robotics, software engineering, test 
technology, and very large scale integra¬ 
tion are participating in the ISS effort. 

During the event, to be held in early 
October, the TCs will present short 
tutorials on their technical areas and 
work cooperatively to tie the technical 
areas together. 

The ISS will be developed using the 
support and facilities of the IEEE satel¬ 
lite network. To increase the audience 
for the symposium, the Computer Soci¬ 
ety is seeking funding from the National 
Science Foundation to line up addi¬ 
tional educational sites for the broadcast. 

For additional information on the 
ISS effort, contact Flazan at (301) 
953-5364. 


Task forces. The task forces on 
professional tools, global change, and 
neural networks are being led by Bob 
Poston, Bernard O’Lear, and Kamal 
Kama, respectively. 

The professional tools TF has estab¬ 
lished two specific pursuits: (1) to 
define standards for tool interfaces and 
(2) to research the need for a tools 
abstracts service and define the possible 
structure for such a service. 

The TF on global change is participat¬ 
ing in current global efforts to monitor 
the world’s environment and to document 
the changes perceived. 

The neural networks TF has recom¬ 
mended that TAB establish a new TC 
on neural nets that would focus CS 
efforts in the intelligent-systems area. 

The TAB and TCs are active in any 
given year, as the focal point for techni¬ 
cal activities within the society. But, 
during the remainder of 1988, you will 
be seeing the TCs engendering a more 
visible presence through an increasing 
number of newsletters to their mem¬ 
bers, and development of plans for 
new, modified, and continuing confer¬ 
ences, workshops, and symposia. In 
addition, more TCs are considering 
sponsoring standards activities. 

The society is a reflection of its mem¬ 
bership, and TC activities are at the 
heart of the society’s purpose of 
advancing the theory and practice of 
computer science and engineering. 

The society’s Member Handbook of 
Resources and Benefits describes the 
objectives and activities of each TC. 
Additional copies of this TC list may be 
obtained by circling Reader Service No. 
197 at the back of this issue of Com¬ 
puter. If you would like additional 
information on the TCs, contact Dave 
Barber at the society’s Washington, 

DC, office at (202) 371-0101. 


UPDATE 


Contributions to Update are welcome. Send news of industrial or university research and of public policy or profes¬ 
sional issues to Update Editor, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720, 


NSF initiates Young Scholars Program 


The National Science Foundation has 
granted 68 Young Scholars awards to 
establish science, mathematics, and 
engineering enrichment projects for 
more than 2,500 high-ability and high- 
potential secondary school students. 

NSF initiated the Young Scholars 
Program this year with funding of $3.7 
million. The program is designed to 
attract students to science careers by 
offering them the opportunity to work 
with research scientists in ongoing 
research projects or in projects of their 
own design. 

Awards are for one year, with a sec¬ 
ond year of support depending on NSF 
review of the project and the availabil¬ 
ity of funds. The average grant size is 
$41,000. Cost-sharing contributions 
total more than $1.7 million. 

The program emphasizes student par¬ 
ticipation in the process of scientific dis¬ 
covery. Projects combine instruction 


and problem-solving with exposure to 
the research environment and research 
methods through laboratory work and 
field trips. The program’s goal is to 
increase the future number of 
university-based scientists and keep 
pace with industry’s need for scientific 
personnel by fostering student interest 
in these fields. 

To maintain student interest, each 
project includes follow-up activities. 
NSF hopes to capture the interest of 
students as early as possible, before 
they opt out of science careers. Project 
directors establish criteria for participa¬ 
tion, with a focus on broad geographi¬ 
cal and demographic representation, 
including particularly young women, 
minorities, and the disabled. 

NSF stipulates that each project 
include career exploration, study of 
techniques and methods, and activity 
focused on the philosophy of science 
and scientific ethics. 


USAB supports tax incentives 
for continuing education 


The IEEE United States Activities 
Board has urged the Senate Committee 
on Finance to support permanent, 
retroactive reinstatement of tax incen¬ 
tives for continuing education. 

In a letter to the chair of the Senate 
Committee on Finance, 1988 USAB 
chair Edward C. Bertnolli said the 
board decried the loss of Section 127 of 
the Internal Revenue Code, which 
ensured such educational incentives. 

Successful commercial use of new 
technologies depends upon workers 
being able to move from one project to 
another, Bertnolli said. Electrical, elec¬ 
tronics, and computer engineers in par¬ 
ticular require lifelong training to keep 
up with technology. The letter stated 


that lifelong education is a legitimate 
cost of doing business, not a fringe 
benefit. 

The potential loss of revenue from 
reinstating Section 127 is far over¬ 
shadowed by the long-term damage that 
will be suffered by the US work force if 
educational incentives are not available, 
Bertnolli said. A hiatus of even a year 
or two will create a loss of educational 
momentum among individual pro¬ 
grams, further imperiling US standings 
in science and technology. 

The USAB urged retroactive rein¬ 
statement of the section because Con¬ 
gress has not legislated alternative 
incentives for continuing education, 
such as tax credits or vouchers. 


COMPUTER 










USAB comments on waivers 
under age discrimination act 


Older engineers suffer disproportion¬ 
ate numbers of layoffs due to the 
stereotype that their knowledge is out¬ 
dated and their experience not relevant 
to state-of-the-art research, according 
to the IEEE United States Activities 
Board. 

In a statement to the House Sub- 
comittee on Employment Opportuni¬ 
ties, 1988 USAB chair Edward C. 
Bertnolli conveyed the board’s views on 
a 1987 rule adopted by the Equal 
Employment Opportunities Commis¬ 
sion that permits unsupervised waivers 
of employee rights under the Age Dis¬ 
crimination in Employment Act. 

Older engineers frequently face job 
termination or early retirement on short 
notice, Bertnolli stated. Employers may 
then demand that the engineers waive 
their rights, at a time when the 
employees frequently don’t know their 
rights and have little time to learn about 
them. 

The EEOC told the board that an 
individual can still file age discrimina¬ 


tion charges after signing this waiver, 
but must prove that the signing was not 
“knowing and voluntary,” according to 
the statement. 

However, Bertnolli asked why com¬ 
panies require unsupervised waivers “if 
they have dealt with employees in a fair 
and legal manner.” The board sug¬ 
gested that waivers be limited to cases 
where the parties involved follow the 
procedures of the Fair Labor Standards 
Act and recommended that all waivers 
be supervised by the EEOC. 

An accompanying USAB position 
statement also emphasized the impor¬ 
tance of engineers as a resource to tech¬ 
nologically oriented companies, the 
importance of continuing education, 
the unique skills and capabilities of 
engineers, the increasing value con¬ 
ferred by experience, and the right of 
engineers to pursue lifetime careers in 
engineering. The statement urged 
employers to refrain from age discrimi¬ 
nation and to focus on merit when con¬ 
sidering recognition and promotions. 


NAE committee reports on 
US economic competitiveness 


To strengthen its competitive position 
in world markets, the United States 
must focus on high-quality products; 
continuous improvement in goods and 
services; an integrated team approach 
to design, development, and produc¬ 
tion; and strong employee involvement, 
according to a National Academy of 
Engineering committee report. 

At the request of the NAE governing 
council, the committee considered the 
role of technology and engineering in 
US economic competitiveness. It con¬ 
cluded that US industry needs to adopt 
new ways to use and manage technology 
if it hopes to match its rivals in the 
world economy. 

The report urged that economic secu¬ 
rity be considered an objective of 
national policy and that a single govern¬ 
ment agency or council be designated to 
serve as a liaison to industry and other 
private groups. It also suggested regular 
government analysis of the factors 
affecting US industrial competitiveness 
in world markets. 

The nation’s less-than-urgent 
response to the problem threatens to 
cause future losses in economic vitality 
and thus in the American standard of 
living, according to the report. Even 


some of the country’s most technologi¬ 
cally advanced industries, including 
semiconductors, telecommunications, 
and computers, face severe challenges 
from international competitors, accord¬ 
ing to the report. 

State governments should support a 
science and technology base because of 
their knowledge of local industry and 
greater flexibility, especially with 
respect to the use of new technologies 
by small businesses, the report stated. 

The committee also recommended a 
study of how universities have been 
affected by joint ventures with commer¬ 
cial groups in research. Specifically, the 
study would investigate how knowledge 
generated in universities is transferred 
to industry. 

Finally, the committee called for a 
national strategy to improve public edu¬ 
cation at primary and secondary school 
levels. 

Copies of the committee’s report. 

The Technological Dimensions of Inter¬ 
national Competitiveness, are available 
from the National Academy of 
Engineering Office of Public Aware¬ 
ness, 2101 Constitution Ave. NW, 
Washington, DC 20418. 


University develops 
transputer OS 

Programmers at Cornell University 
have developed an operating system for 
the Inmos transputer that allows users 
to organize the solution of problems on 
parallel computers consisting of arrays 
of transputers, according to the uni¬ 
versity. 

The Trillium system manages pro¬ 
cessing and communications on the 
transputer array and on attached front- 
end computers and workstations. It also 
allows users to program transputers in 
Fortran and C. Trillium commands are 
compatible with Unix. 

The operating system was developed 
in the Advanced Computing Facility of 
the Cornell Theory Center by program¬ 
mers Gregory Burns, Andrew Pfiffer, 
and David Fielding under the direction 
of the center’s associate director, Alison 
Brown. 

The first implementation of Trillium 
is for the T-Series from Floating Point 
Systems. The center has a 16-node T- 
Series computer. 

For more information, contact Cor¬ 
nell University, News Service, Village 
Green, 840 Hanshaw Rd., Ithaca, NY 
14850-1548, phone (607) 255-4206. 
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Why nor rake rhe shortest and fastest route 
toward system design solutions? To define 
and model a large, complex system, you 
need a modeling tool that con address the 
system's total architecture. 

44 PAWS/GPSM™ is on easy-to-use high 
productivity modeling and simulation 
tool that lets you evaluate alternative 
architectures while focusing on performance. 
It provides o state-of-the-art environment for 
developing accurate and reliable product 
definitions. 

44 PAWS provides high level primitives 
closely resembling the user's intuition. 
mb* PAWS models rhe behavior of a total 
system implemented in diverse technologies 
including software, hardware, and firmware. 


M. GPSM, the graphical interface to 
PAWS, helps you quickly and easily 
transfer your ideas into pictures. GPSM 
helps you visualize multiple data and control 
flows through several components and 
incrementally synthesize models of a total 
system. 

4 4 PAWS/GPSM is flexible. It lets you refine 
your model os your system design 
evolves so you con eliminate potential 
problems as early os possible in the product 
design cycle. 

Call (512) 474-4526 to receive information 
on PAWS/GPSM. And get on rhe PAW5 
expressway to system design solutions. 
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Information Research Associates • 911 W. 29th St. • Austin, Texas 78705 • ( 512 ) 474-4526 






































NEW PRODUCT REVIEWS 


Editor: Richard Eckhouse, MOCO, Inc., PO Box A, 91 Surfside Rd„ Scituate, MA 02055; Compmail+, r.eckhouse 


Mathematical-oriented programming 

Allen L. Wasserman, Oregon State University 
Richard H. Eckhouse, New Product Reviews editor 


From Fortran to APL, a prolifera¬ 
tion of programming languages claim to 
make it easier to write programs that 
solve problems. But in all cases, two 
stumbling blocks interfere with making 
this an easy task for the casual com¬ 
puter user. First, the user must be able 
to express what is to be done and how it 
is to be accomplished. Second, the user 
must know how to program. While the 
technically inclined may enjoy writing 
programs, many users would prefer to 
state a problem and leave it to the com¬ 
puter to find the answer. 

It is tantalizing to think of future 
generations of computers as devices 
capable of accepting abstract ideas and 
organizing them into some form of 
knowledge usable in solving problems. 
Although this view of computing is cur¬ 
rently not realistic, we can tap the 
potential of today’s machines to pro¬ 
vide better tools for the non-computer- 
oriented problem solver. A first step 
would be to create systems that trans¬ 
form mathematical expressions into 
useful results. The two products 
reviewed here are examples of such sys¬ 
tems for the Macintosh and the PC. 
Wasserman reviewed Math View 
Professional and Eckhouse reviewed 
MathCAD. 


Math View Professional 
Version 0.94 

Math View Professional (MVP) is a 
self-contained mathematics application 
capable of performing a nearly encyclo¬ 
pedic range of mathematical, graphical, 
and statistical operations. The follow¬ 
ing review briefly summarizes the pro¬ 
gram’s features, touches on the manual 
supplied with the review copy, offers 
some details about the program, and 
suggests some future improvements. 

MVP in brief. The mathematical 
operations include the more common 
matrix procedures, numerical integra¬ 


tion, special function evaluation, non¬ 
linear algebraic system equation 
solving, and ordinary and partial 
differential equation solving. 

Plotting routines are available in 
either two or three dimensions. They 
can be used separately or as graphical 
displays of results from certain mathe¬ 
matical operations. 

In two dimensions, you can plot 
either data or functions. Three- 
dimensional plotting can be done with 
or without hidden-line removal. A 
limited text-insertion facility allows you 
to title graphs and label axes. Graphs 
can be copied to the Macintosh clip¬ 
board for insertion into text processors 
or for additional editing by programs 
such as SuperPaint or MacDraw. (For 
reasons probably better understood by 
MVP’s authors, copying, pasting, and 
other command responses in windows 
holding graphs copied from MVP pro¬ 
cess very slowly, or not at all.) 

MVP, by design, primarily processes 
operations one at a time, like a calcula¬ 
tor. But thoughtful integration of text 
file facilities in some instances permits 
several related operations to be stacked. 

Floating-point calculations use the 
80-bit extended data type with Apple’s 
SANE (Standard Apple Numeric Envi¬ 
ronment) library routines to maintain 
an accuracy of 19-20 decimal digits with 
an exponent range of - 4932 to + 4932. 
Because MVP functions like a calcula¬ 
tor and because it must take time to 
parse screen-introduced input, speed 
benchmarks have little meaning. It is 
sufficient to note that, although most 
procedures execute with adequate 
speed, a floating-point coprocessor is a 
distinct asset. MVP runs on the Macin¬ 
tosh Plus, SE, or Macintosh II. It func¬ 
tions without apparent difficulty on the 
SE and Plus fitted with accelerator 
boards. 

Using SANE allows systems with 
floating-point coprocessors accessed by 
SANE intercepts (such as Macintosh IIs 
and Macintoshes fitted with accelerator 
boards) to take advantage of coproces¬ 


sor hardware and perform floating¬ 
point calculations with roughly a five 
times improvement in speed. However, 
MVP is not hard-coded for the 68881 
and cannot take maximum advantage 
of coprocessor speed. 

According to the company, MVP 
requires a minimum of 512 Kbytes of 
RAM. But MVP itself resides on three- 
fourths of an 800-Kbyte disk and seems 
to want that much RAM, so running 
with less than one megabyte might be 
frustrating. Moreover, to take advan¬ 
tage of important file manipulation 
capabilities, the minimum practical 
mass storage requirement is an 
800-Kbyte external disk drive. But 
working without a hard disk surely han¬ 
dicaps the user. Moreover, I had no 
success using MVP with Switcher, 
although the manual claims that MVP 
can be run with Apple’s Switcher 5.1 or 
higher. 

A few practical limitations appear in 
the generality of some routines. Matrix 
inversion and eigenvalue solving, for 
example, are limited to real matrices, 
and partial differential equations are 
solved in only two dimensions. But 
MVP’s stated design objective of broad 
mathematical scope within a self- 
contained, compact, and convenient 
application has generally been achieved, 
and these compromises in no way 
diminish the value of the program. 

I received Version 0.94 of Math View 
Professional for review, which suggests 
that a final version has yet to be mar¬ 
keted. I do not know which version the 
company actually retails. The adver¬ 
tised price is $249.95, with a demonstra¬ 
tion disk available for $10. It is not 
copy protected. 

User’s manual. The version of the 
MVP manual I received was obviously 
undergoing minor revision. But it is a 
clearly written 122-page manual that 
instructs through detailed examples of 
every mathematical and graphing oper¬ 
ation and file manipulation that MVP 
can perform. The last section of the 
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Figure 1. Algebraic systems problems. 



Figure 2. Roots and zeros. 



Figure 3. Ordinary differential equations. 


manual contains supplementary techni¬ 
cal notes, descriptions, and literature 
references for the various routines and 
algorithms employed. 

The manual deserves much praise. 
But the version submitted suffers nota¬ 
bly from the lack of an index or even a 
table of contents. Surely that will be 
remedied in the marketed version. 
Projecting ahead to a final version, the 
manual should be quite helpful. 

MVP in detail. MVP is so laden with 
applications that an appraisal of each 
would be burdensome. A few of MVP’s 
more useful and unusual capabilities 
will therefore form the basis of this 
section. 

After you double-click the applica¬ 
tion icon from the finder and then 
single-click anywhere in the resulting 
MVP logo screen, a standard Macin¬ 
tosh menu bar displays File, Edit, and 
Application Option. File and Edit are 
the usual Macintosh file and text facili¬ 
ties and require no further explanation. 
Under the Applications Menu come the 
11 gateway categories into which MVP 
is organized: 

• Algebraic Systems Problems (see 
Figure 1) 

• Roots and Zeros (see Figure 2) 

• Ordinary Differential Equations 
(see Figure 3) 

• Integrals (see Figure 4) 

• Special Problems (see Figure 5) 

• Optimization (see Figure 6) 

• Series Operations (see Figure 7) 

• Function and Data Plotting (see 
Figure 8) 

• Statistics (see Figure 9) 

• Partial Differential Equations (see 
Figure 10) 

• Evaluate and Tabulate Functions 
(see Figure 11) 
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Figure 4. Integrals. 



Figure 5. Special problems. 



Figure 6. Optimization. 
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Figure 7. Series operations. 


Let’s look at a typical example of 
how MVP functions. Opening the Spe¬ 
cial Problems menu, you see a dialog 
box with three subcategories available 
for this menu item, each preceded by a 
circular “button.” Clicking in the 
desired button and then clicking “OK” 
(or pressing Return from the keyboard) 
activates the requested routine. If you 
select the Special Functions sub¬ 
category, a new dialog box appears, list¬ 
ing 20 special functions such as Bessel 
functions, elliptic integrals, and so 
forth that MVP can evaluate. 



Figure 8. Function and data plotting. 



Figure 9. Statistics. 



Figure 10. Partial differential equations. 


Selecting the desired special function 
produces another dialog box requesting 
the parameters that define the function 
to be evaluated. After you supply the 
requested parameters and click “OK” 
(or press the Return key), the result is 
displayed (in about four seconds on an 
SE) with 10 digits of either scientific or 
fixed-point notation. 

Some unusual and useful features of 
MVP can be illustrated by an example 
from the Evaluate and Tabulate Func¬ 
tions menu. Selecting this item produces 
a dialog box in which you can define 
and then evaluate an arbitrary function 
constructed from any arithmetic combi¬ 
nation of the usual collection of tran¬ 
scendental as well as the 20 special 
functions. Although one can always 
quibble about omissions from the spe¬ 
cial function list, the capacity for defin¬ 
ing functions is so broad that many 
special functions not explicitly included 
are implicitly included. For example, 
since the Beta function is expressed as a 
product of Gamma functions, it can be 
calculated. The authors used this facil¬ 
ity to calculate some of the special func¬ 
tions used in MVP. 

Tables of special functions or user- 
defined functions can also be created 
using the tabulate selection and then, if 
desired, carried over to MVP’s plotting 
routine and plotted as “raw data” or 
with a spline curve fit. The “raw data” 
plotter has the persistent habit of con¬ 
necting “data” points with straight line 
segments, which can produce distract¬ 
ing and inaccurate graphical representa¬ 
tions. In keeping with data-plotting 
objectives, it would be better to have 
the option of not connecting the data 
points. The function tables can, how¬ 
ever, be rescued from MVP by minor 
editing with a text processor and 
importing the file into Cricket Graph or 
some other dedicated graphics appli¬ 
cation. 

Many operations allow data to be 
entered from the screen or from a stan¬ 
dard formatted text file. The manual is 
explicit on the format required as input 
to specific applications. Moreover, the 


92 


COMPUTER 


















































































































Figure 11. Evaluate and tabulate functions. 


results from many applications are 
organized by MVP into formatted text 
files that are correct input for other 
applications. Herein lies the ability, in 
some cases, to stack successive 
procedures. 

For example, the results from matrix 
operations, if saved to a text file, can be 
used in other matrix operations. The 
inverse of the matrix product A*B can 
be taken by saving the result of the 
matrix multiplication as a text file and 
then using this file as input to the inver¬ 
sion program without leaving MVP or 
editing the file in any way. 

Many procedures allow the results to 
be graphically represented. For exam¬ 
ple, after the solution to a differential 
equation by the Runge-Kutta method is 
obtained, a dialog box gives the option 
of a graph of the solution. Partial 
differential equation routines include an 
option for a series of time-evolving 
graphs. 

Graphs generated by MVP can be 
titled and labeled by turning Graph 
Text on from the options menu. A text- 
entry cursor then appears and nine- 
point Courier text can be written any¬ 
where in the graph window. This is a 
very unforgiving text-entry facility, 
because text entered in this manner can¬ 
not be edited except with the backspace 
key. Moreover, once the text is “set” 
by moving the text-entry cursor, no fur¬ 
ther editing or deleting is possible. 

Function differentiation and partial 
differentiation are performed under the 
Differential Equations menu. Functions 
submitted for differentiation can also 
include special functions. It would have 
been useful to extend this facility with a 
“tabulate derivatives” option to create 
tables (and graphs) of derivatives. 

Under the Integrations menu you 
find the usual assortment of one¬ 
dimensional (and multidimensional) 
numerical integration routines. Some 
forms of improper integral (but not the 
fairly common principal value) can also 
be evaluated. 


Summing up. MVP is not a subrou¬ 
tine library and is not intended to be 
used as an overlay for more ambitious 
programs. On the contrary, MVP as a 
separate application does not require 
any programmer skills. With only the 
manual at your side (and someday per¬ 
haps a help screen to remind you of the 
meaning of specialized parameters or 
notation for the special functions), you 
can direct MVP to do more than 
enough mathematics and plotting (or 
provide text files for dedicated plotters) 
to warrant a place on your hard disk. 
This holds for anyone with serious 
mathematics requirements or those who 
merely find pleasure in mathematical 
pursuits. 

Because earlier versions of Macintosh 
computers were relatively slow in 
floating-point processing, there was no 
stampede to produce serious 
mathematics software. With this latest 
generation of Macintoshes and accelera¬ 
tor boards with math coprocessors, I 
have no doubt that math applications 
and adaptations of libraries will start to 
appear. But for the present, MVP 
stands quite alone among mathematics 
packages for the Macintosh. For a hun¬ 
dred dollars more, maybe Brainpower 
should throw in the source code. 
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MathCAD 2.0 

MathCAD in brief. The selling point 
for MathCAD has been its natural style, 
which lets you enter free-form mathe¬ 
matical expressions the way you would 
enter text into a word processor. When 
you start the program, you are 
presented with a message line at the top 
of the screen followed by 24 lines of 80 
columns that constitute the scratchpad 
entry form. A flashing cursor indicates 
where text, variables, equations, or 
graphs may be placed. Using the arrow 


keys, you move the cursor to place new 
information as your document grows. 

MathCAD calculates equations and 
defines variables in a document from 
left-to-right and top-to-bottom. Each 
equation and collection of text is called 
a region. Normally, the limits of a 
region are invisible, but a command can 
be used to display a region if its bound¬ 
aries are not intuitively obvious. Other 
commands allow regions to be cut and 
pasted, either to reorganize the docu¬ 
ment or to separate overlapping 
sections. 

When setting up a problem, you 
would normally define your variables, 
enter some equations, and then let 
MathCAD calculate the results. The 
results can be single or complex values, 
tables, or color graphs. Comments can 
be freely inserted to describe what’s 
being defined or solved for. 

The first version of MathCAD 
included 19 operators and a large num¬ 
ber of built-in functions. Besides the 
obvious basic arithmetic operators were 
factorial, subscript, power and square 
root, summation, product, derivative, 
integral, and complex conjugate. The 
functions included trigonometric, 
exponential, statistical, and Bessel, as 
well as cubic spline, regression, and a 
fast Fourier transform and its inverse. 

In version 2.0, the list of operators 
has grown to 29 with the addition of 
superscript, vectorize, and matrix oper¬ 
ations. File access, FFT, and miscel¬ 
laneous functions have been expanded, 
and new classes for matrix and vector 
operations, as well as an equation 
solver, have been added. Plots are now 
auto-scaled, the system has been 
speeded up, and new support has been 
added for text input and plotter/printer 
output. Of course, all of this takes more 
memory, so the system requirements 
have been upped to 512 Kbytes. 

Other system requirements are an 
IBM PC or compatible with DOS 2.0 or 
later, a graphics card, one floppy drive, 
and a graphics printer or plotter for 
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MathCAD 2.0 features standard math symbols, evaluation of formulas and genera¬ 
tion of plots in a free-form document, automatic unit conversions, matrix arith¬ 
metic, and equation solving. 



MathCAD uses free-form notation, plotting, and functions like the fast Fourier 
transform to create custom applications such as the signal processing example 
shown here. 


output. While a coprocessor is not 
required, it and a hard disk are sup¬ 
ported and recommended. The system 
now supports the LIM expanded mem¬ 
ory specification, but only plots and 
arrays are stored in it. 

The price of MathCAD 2.0 is $349, 
with an upgrade price of $50 plus ship¬ 
ping to users of earlier versions. This 
price includes toll-free technical sup¬ 
port, a newsletter, and many sample 
documents that fully illustrate the 
power of the system. 


User’s manual. The user’s manual 
has been revised and expanded from the 
previous version. While the last manual 
was well done, the new manual is even 
better. It carries on the tradition of 
being both tutorial and referential at the 
same time. There are 17 chapters and 
five appendixes, each well illustrated 
with samples and corresponding 
screens. The commands for each chap¬ 
ter are highlighted and set out before 
they are described. 

I liked the way the writers of the 


manual anticipated some of the prob¬ 
lems the reader might encounter while 
learning the system. For example, in 
issues related to parentheses, knowing 
where to place the cursor can be impor¬ 
tant. Five screens make this clear; two 
boxes of italicized text offer additional 
comments and suggested shortcuts. In a 
similar fashion, when dealing with vec¬ 
tor versus subscripted notation, the 
manual warns that if you use subscripts 
when they are not required, or vice 
versa, you probably won’t get the 
answer you’re looking for. A few rules 
of thumb on when to use subscripts 
assist the reader. 

The manual includes both a table of 
contents and a full index. For the new 
user, a preface describes what Math¬ 
CAD is, its features, and how to use the 
manual. Chapter zero describes how 
you set up MathCAD on your system. 
Subsequent chapters go from the basics 
through editing, formatting, and print¬ 
ing before turning to more complicated 
computational features. The pedagogi¬ 
cal approach of the first six chapters 
gets you up to speed fast so that your 
interest is maintained. 

The next nine chapters go through 
equations and computation, names and 
numbers, units and dimensions, vectors 
and matrices, range variables and itera¬ 
tion, operators, built-in functions, 
equation solving, data files, and plot¬ 
ting features. The last chapter includes 
six MathCAD examples. The appen¬ 
dixes include a reference section, error 
messages, start-up options, printer 
drivers, and numerical methods. If you 
make it all the way through, you are 
certain to be a MathCAD whiz. 

MathCAD in detail. When first 
started, MathCAD recognizes the 
installed graphics adapter and presents 
a “boilerplate” screen in the appropri¬ 
ate graphics mode. The top line of the 
screen gives the current file name on the 
left and the current line and column 
numbers on the right. Immediate com¬ 
mands appear between the two when 
you press the Esc key or a function or 
control key. You can invoke pull-down 
menus by pressing the F10 key. Unfor¬ 
tunately, mouse support is not offered 
to speed up command selection. 

A screen can grow downward and to 
the right as you type in new informa¬ 
tion. Ordering of information is defined 
in the same manner, so that equations 
depend on values previously defined to 
the left and above. 1 find this a natural 
way to develop a screen, but there were 
times when I moved regions containing 
values and formulas so that they were 
no longer defined before I used them. 
The on-screen error messages clearly 
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point to such inconsistencies, which you 
can easily and quickly correct. 

MathCAD has a rich set of symbols 
using the extended PC character set. 
Included are the Greek characters, inte¬ 
gration, summation, and product, to 
name a few. Predefined values exist for 
pi, infinity, e, and percent. To format 
results, there are predefined values for 
the radix, complex tolerance, imaginary 
symbol (/ or j, depending on the user’s 
background), the threshold for convert¬ 
ing to exponential notation, and the 
precision. Other predefined values 
specify the tolerance used in numerical 
approximation algorithms, the array 
origin, and the column width and num¬ 
ber of decimal places used when writing 
data to ASCII files. The use of ASCII 
files for data is a handy feature when 
you want to import and export data to 
another program like a spreadsheet. 

When you develop a screen, standard 
keys take on many special functions. 

For example, a subscript is started by 
the [ key, the square root is triggered by 
the \ key, and & is used to develop an 
integral. To define a variable, t, and set 
it equal to 10, you would type t: 10. On 
the screen it would appear as t: = 10. If 
instead you typed t: 1; 10, the screen 
would look like t: = 1 .. 10 to indicate 
that t takes on a range of values from 1 
to 10. Since nonintegral steps might be 
required, the range statement has the 
more general form of x,y;z indicating 
the first value, x, the second value, y, 
and the final value, z, from which the 
range can be determined. While this 
MathCAD notation may take a bit of 
getting used to, it translates into a 
screen display or hard-copy image that 
makes this system very useful. 

Additional special keys include the @ 
key to set up and the f key to format a 
plot; the “ to define a text region; and 
combinations of the function keys (with 
Alt and Ctrl) for cutting, pasting, 
searching, windowing, recalculating, 
etc. Using both the help screen and the 
pull-down menus provides a useful 
alternative to remembering the correct 
key command sequence. Even more 
helpful is the quick reference guide 
included with every version. 

I’ve always found plotting a powerful 
feature for explaining a mathematical 
concept, and MathCAD’s method for 
generating plots is both versatile and 
intuitive. You open a plot region by 
typing an @ and then providing the x 
and y functions to be plotted. Math¬ 
CAD will automatically scale the plot 
and set the limits for the x and y axes. 
Of course, you can fill these values in, 
if you wish. You can also specify the 
type of plot (one of 13 types including 
line, dot, error bars, bar charts, exes, 


pluses, and diamonds), the plot size, the 
number of subdivisions, and whether 
the axis is linear or logarithmic. 

Another unusual feature of Math¬ 
CAD is that it offers dimensional 
checking by providing dimensional 
values for mass, length, time, and 
charge. Variables defined in terms of 
the dimensional values are called units. 
You can use these units to detect con¬ 
sistency and to provide additional error 
checking. For example, having defined 
the base units, you can next define 
other units in terms of them: 

cm 

dyne = g- s 2 

Using this feature, MathCAD provides 
both dimensional consistency and auto¬ 
matic conversion between units. 

A new feature in version 2.0 is the 
ability to solve equations. The root 
function finds the zeros of an arbitrary 
expression. Since this is equivalent to 
solving a single equation for one 
unknown, the program also provides a 
solve block to solve simultaneous equa¬ 
tions operating under constraints. And 
since MathCAD handles both real and 
imaginary values, it will solve for com¬ 
plex as well as real roots. 

An example of using solve would be 
to find x and y values that satisfy 

^ + y = 6 

and 

x + y = 2 

with the condition that y>2. To start 
the solver, you provide some initial 
guesses for x and y. The Find function 
will iterate until it finds one solution 
(there may be multiple solutions requir¬ 
ing different guesses) or it quits. Quit¬ 
ting occurs when the solver reaches (1) a 
point where it cannot reduce the error 
vector any further, (2) a point where 
there is no basis on which to make fur¬ 
ther iterations, or (3) the limits of its 
accuracy. In this latter case, assuming 
there is a solution, you can make new 
guesses and start over. 

Because MathCAD maintains 15 dec¬ 
imal digits of accuracy, solving simul¬ 
taneous equations and using complex 
built-in functions or operators may take 
time. You may not notice this at first 
while you’re editing an equation, 
because MathCAD does not process it 
until you move out of the region it 
occupies. The computational time for 
processing of an equation or plot 
becomes obvious when you start to 
scroll over a screen and suddenly find 
the scrolling stopped and a flashing 


“wait” message at the top of the 
screen. The program has suspended 
screen updates until the computation 
has finished. Fortunately, you can sus¬ 
pend the normal mode of automatic 
processing either by interrupting it as it 
occurs or by putting the system into 
manual mode. In manual mode, pro¬ 
cessing only occurs when you press the 
F9 key. 

A point not to forget is that Math¬ 
CAD is a numeric, not a symbolic, cal¬ 
culator. Thus, the result of differentiation 
is a single value, not a function. Also, 
since specific numeric algorithms are 
used, these algorithms can be “fooled” 
by ill-behaved expressions that contain 
singularities, discontinuities, or large 
and rapid fluctuations. 

Matrices are another new feature of 
version 2.0. Included with them is a 
large set of matrix operations. Besides 
the arithmetic operators, the new 
matrix operators include inverse, mag¬ 
nitude, transpose, cross product, sum, 
complex conjugate, and element extrac¬ 
tion. Functions provide for determining 
the size of a matrix (number of rows, 
number of columns, or length and index 
of the last element of a vector), the 
maximum and minimum values, and 
real and imaginary parts. Particularly 
nice is the ability to perform vector 
operations. 

The vector operator changes the 
meaning of the other operators and 
functions so that they are applied ele¬ 
ment by element on the vector. Thus, if 
x is a vector, then the vector operation 
on sin(x) means that the sine function is 
applied to all the elements of x. Vectors 
have two advantages. First, you can use 
scalar expressions with vector values. 
Second, the vector operator is often 
much faster than subscripts and range 
variables for the same scalar or matrix 
operation. 

Summing up. This is not the first 
time I have reviewed MathCAD. I have 
had the pleasure of watching this prod¬ 
uct grow and mature, yet I have felt 
that each version was worthy of pur¬ 
chase. I have recommended it in the 
past (and still do) as a valuable tool that 
allows users to quickly illustrate and 
solve a problem without having to write 
a program. The ease with which vari¬ 
ables and equations can be changed and 
results regenerated makes this an excel¬ 
lent “what-if” type of utility. What’s 
really nice is the ability to interactively 
solve a problem and then print out the 
results in a form that 1 can share 
immediately with my nonprogrammer 
colleagues. 
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Light accounting? What’s that? 


J.G. Eckhouse, PetroHouse 

A good program doesn’t need a corny 
gimmick to sell it. Dac thinks it does. 
The manual cover for Dac-Easy Light 
shows a big beer can, with the word 
“Light” in large typeface, then the 
statement “Less Filling Accounting For 
Home and Office.” The enclosed flyer 
shows “The New Light Controversy” 
with Roger Starbaugh and Terry Brad¬ 
shaw pointing fingers at each other. 
Roger says “Dac-Easy Light is perfect 
for office accounting” and Terry 
retorts “Wrong, Light is perfect for 
home accounting!” As far as I am con¬ 
cerned, Terry is definitely wrong and 
Roger is right only if instead of “per¬ 
fect” he had said it’s OK but far from 
perfect. Dac should have saved the high 
fees for the stars and hype and spent it 
on program development and improv¬ 
ing the manual. 

Dac apparently took one of their 
excellent general accounting programs 
(which sells for only a little more) and 
tried to simplify and adapt it for small 
business and home use. Actually, it has 
some very nice features for a small busi¬ 
ness, but the transaction entry and 
retrieval is too cumbersome. For home 
use, the excellent business features, 
such as the ability to print invoices and 
monthly customer statements, hold lit¬ 
tle interest. 

Add the poor entry system and par¬ 
ticularly the use of double-entry 
accounting, which I don’t like for home 
use, and you can understand why 1 will 
definitely stick with the cheaper and 
better program I am now using 
(Quicken) for tracking my checking 
accounts, expenses, income, and 
budget. I learned my current system in 
an hour. After many hours of trying to 
use Light, I still don’t feel comfortable 
with it. 

Having said all that, 1 can say that if 
you want a double-entry system and are 
willing to expend a little effort in learn¬ 
ing the program and in learning how to 
avoid frustration using it, then Light 
may well be just the ticket. 

In spite of all my facetious com¬ 
ments, Light does have some very nice 
features. The budgeting system is excel¬ 
lent, even if it does take quite a bit of 
work to set up. Invoicing is a snap. The 
ability to prepare customer statements 
is a nice feature, too. Light can track 
assets and liabilities nicely, and then 
come up with a complete balance sheet. 
The report forms are quite good, but 
they require a wide-carriage printer. I 
was able to generate some of them on 


an 8K-inch sheet using a 17-cpi font, but 
they’re harder to read. Part of the prob¬ 
lem is too much spacing in both 
columns and rows. 

A few of the items I found undesira¬ 
ble were 

(1) the difficulty—nay, sometimes 
impossibility—of editing trans¬ 
actions; 

(2) no quick keys for finding a chosen 
category from the list; 

Nutshell Plus—the 
manager (Version 1, 

Michael M. Dediu 

For me, Nutshell is like a large, cross- 
referenced file cabinet where you can 
find information quickly—all the text, 
numbers, and dates used for letters, 
reports, budgets, billings, and so on. 

You can sort the records in any order, 
produce forms and reports, and get cal¬ 
culations and summaries of the data. 
After putting data in Nutshell files, you 
can use it for different applications, 
such as printing customized form letters 
and mailing labels, preparing invoices, 
printing Rolodex cards, and compiling 
statistics. The different arrangements 
for forms, form letters, reports, labels, 
etc., can be stored in files and used 
again easily. 

I found useful the fact that you can 
combine the data from different linked 
files, thus avoiding the duplication of 
information. Nutshell can copy data 
directly from other file formats, such as 
dBase, DIF, and ASCII. It also can 
automatically check new data for 
accuracy. 

I like Nutshell’s macros, because you 
can use them to automate many routine 
tasks. 

The number of records in a file is 
limited only by disk space, to a maxi¬ 
mum of 32 Mbytes on a hard disk. 
Creating a new file is quite easy—you 
define a field for each category of infor¬ 
mation you need to store in the records 
(up to 60,000). There are five types of 
fields: text, number, date, calculation, 
and summary. 

To link one file to another, both files 
must have at least one field in common. 
To define a link, you specify at least 
one pair of common fields (called a 
“field pair”). By matching the data 
from the field pairs for each record in 


(3) no journal report showing each 
transaction with date, number, 
payee, withdrawal, deposit, and 
balance on one line (this takes up 
about 6 lines in Light); and 

(4) no good way of querying the data 
base by payee, category, etc. 

The check-writing feature is awkward, 
but will work. Other entries, such as 
recording manual checks, deposits, and 
withdrawals, could be better handled 
with a conventional three-column jour¬ 
nal screen. 

Dac-Easy Light costs $69.95. 
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the base (or primary) file, Nutshell finds 
all the records in the lookup (or secon¬ 
dary) file where the fields match, but 
uses only the first matching record for 
display on layouts, in calculations, for 
sorting, and for summarizing. Here the 
zoom option really helps; with it you 
can see all matching records. If you 
change data in the base file, Nutshell 
automatically finds the new matching 
records. 

1 found one point really useful: All 
the things you can do with the data in 
one file, you can also do with the com¬ 
bined data of any of the linked files. 

One point I don’t like: You can make 
changes only to the current file (the file 
you are currently working with). On the 
other hand, using the zoom option you 
can transform any lookup file in the 
current file. In fact, anything you can 
do in the base file, you can also do in a 
lookup file, simply by zooming. You 
can sort data from both the base file 
and lookup files together, summarizing 
the data on layouts in the base file. 
Multiple layouts allow you to view the 
same data in a number of ways. 

Nutshell Plus is a practical tool for 
handling data files. It runs on IBM PC, 
PC XT, PC AT, Personal System/2, 
and compatible computers with DOS 
version 2.0 or higher and supports the 
Intel 8087 and 80287 math coprocessor 
chips. It is compatible with Microsoft 
Windows, DESQview, TopView, and 
DoubleDOS. 

Nutshell Plus costs $295. It requires 
at least 384 Kbytes of RAM and one 
disk drive, and a second floppy disk 
drive or hard disk is recommended. 
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Hot Line Electronic 

Michael M. Dediu 

.1 found General Information’s Hot 
Line version 2.0 a useful electronic 
phone book and automatic dialer, giv¬ 
ing fast telephone and address informa¬ 
tion. The package includes a database 
of 10,000 phone numbers and addresses 
of airlines, hotels, major corporations, 
and colleges. The database is in Ashton¬ 
Tate’s dBase III format and you can 
append, update, and delete entries. 

Hot Line allows for large, custom 
personal directories as well. It can be 
installed memory resident (72 Kbytes to 
85 Kbytes) or stand-alone and has net¬ 
working capabilities. It can log and time 
calls, exchange data with other pro¬ 
grams, dial phone numbers from the 
computer screen or the numeric keypad, 
find area codes and local times for 
3,000 US and foreign cities, and find 
every US and Canadian area code. I 
found it reasonably easy to use (menu 
driven) and fast enough on a 4.77-MHz 
PC that the information was displayed 
almost without delay. 

This software effectively links four 
features: the quick-access indexed data¬ 
base format, the RAM-resident pro¬ 
gramming feature, a personal modem, 
and a voice telephone. I think this soft¬ 
ware would be of great utility to anyone 
who frequently uses both a telephone 
and a personal computer. 

You activate Hot Line with any of a 
set of hot keys involving the Alt and 
function keys. Each hot-key combina¬ 
tion activates a separate function. One 
combination activates a menu leading 
to all individual functions. 

The first function, the National 
Directory, is an indexed directory of 
10,000 businesses and institutions with 
their telephone numbers and addresses. 
You access the entries by the name of 
the company or by a pattern in the 
name. 

1 was disappointed to find many com¬ 
panies and institutions important to me 
missing, but you can easily correct this 
deficiency by appending the current 
database. You can also edit or delete 
any errors. In general, the search is fast 
and accurate if you know the name of 
the company and spell it correctly. The 
search algorithm fails for misspelled 
words, stopping the search when the 
first unmatched character is 
encountered. 

The second function is the Private 
Directory. This directory must be 
created as a database file and may con¬ 
tain a large number of personal 
numbers. 


Phone Book 


The third function is called City 
Lookup. This database contains the 
area codes for more than 3,000 cities 
around the world, plus the local time 
according to system time. 1 found this 
feature useful for international calls. 

The next function is called Keypad 
Dial. If you have a Hayes-compatible 
modem and a phone attached, you can 
use the keyboard keypad to dial a num¬ 
ber and connect the phone for voice 
communication. 

The fourth function is Speed Dial. 
You use this to dial any of a set of num¬ 
bers immediately. 

The fifth function, Cursor Dial, dials 
the number specified by the current cur¬ 
sor location on the screen. 

I found the abundance of hot keys 
inconvenient when using other software 
packages, such as Word Perfect, that 
use the same keys for a variety of func¬ 


tions. The conflict requires you to 
remove Hot Line before proceeding. 

The program is available for the IBM 
PC, PC XT, PC AT, PS/2, and true 
compatibles, using any monitor except 
the PGA or RAMfont mode of the Her¬ 
cules Graphics Card Plus. Hot Line 
works with Hayes and Hayes-compatible 
modems with pulse or touchtone tele¬ 
phones and any PBX system that can 
handle a standard modem or a standard 
single-line phone. It comes with a 
30-day money-back guarantee. 

The documentation, although easy to 
use and informative, could be improved. 
On a scale of 1 to 100,1 estimate the 
performance of Hot Line at 87, its ease 
of use at 91, and the documentation at 
79. 

Hot Line costs $75. The company has 
provided several free updates. While 
other programs may offer similar fea¬ 
tures for less money, the real value of 
this software lies in its extensive indexed 
directories. 
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Measuring program complexity 

Daniel McAuliffe, McDonnell Douglas Astronautics 


Every software developer has at one 
time or another faced the problem of 
determining the complexity of a partic¬ 
ular piece of software. This information 
is often useful in determining the num¬ 
ber of manhours required to develop a 
related or similar software package. 

The simplest, and probably most com¬ 
monly used, measure of program com¬ 
plexity has been a count of the number 
of lines of code. Although this metric 
provides an adequate estimate of pro¬ 
gram size, it can fail miserably at meas¬ 
uring program complexity. PC-Metric 
Version 1.1, from Set Technologies, 
attempts to provide a more comprehen¬ 
sive set of complexity metrics for the C, 
Pascal, or Modula-2 programmer. 

The output from PC-Metric consists 
of two reports. The first report comes 
in two parts. The first part provides a 
set of various complexity metrics for 
each of the subprograms in a given 
source file. The second part summarizes 
the set of metrics for the entire source 
file. The second PC-Metric report pro¬ 
vides a list of deviations of each subpro¬ 
gram from a set of standards consisting 
of items such as lines of code in a proce¬ 
dure, programmer error rate, and pro¬ 
grammer speed. 

PC-Metric uses two sets of complex¬ 
ity metrics: the Software Science family 


of metrics and the Cyclomatic Com¬ 
plexity metrics. The Software Science 
metrics are based on the following 
parameters: 

nl: number of unique operators 
n2: number of unique operands 
Nl: number of total operators 
N2: number of total operands 

The program length 

N = Nl + N2 

and predicted program length 

N = nl x log(nl) + n2 x log(n2) 

are used to develop the Purity Ratio, 
which is the ratio of the estimated 
length to the measured length. The 
other Software Science metrics are the 
program volume 

V = N x log(n) 

and a quantity called Effort, which is 
based on the ratio of volume to esti¬ 
mated abstraction level. This last quan¬ 
tity is 

L = 2/nl x n2/N2 
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The Cyclomatic Complexity metrics 
consist of the cyclomatic number and 
the extended cyclomatic complexity. 
Additional program metrics, such as 
lines of code and the number of 
executable semicolons, are also included 
in the program output. 

The manual contains an excellent 
tutorial on the subject of program com¬ 
plexity, with special attention given to 
Software Science and Cyclomatic Com¬ 
plexity metrics. It also includes a section 
on the use of PC-Metric as a feedback 
tool. Procedures are described for 
evaluating the program output. The 


authors suggest developing sets of 
means and standard deviations for 
those metrics of interest to the user and 
using these statistics to evaluate the 
degree of complexity of the program 
under evaluation. PC-Metric itself does 
not provide these statistics. It would 
seem an easy matter to add these fea¬ 
tures to the program and save the user a 
lot of unnecessary calculation. 

I tested PC-Metric on a set of C lan¬ 
guage programs of varying complexity. 
Although no quantitative measures of 
actual development time were available, 
the different program metrics agreed 


with my intuitive sense of the difficulty 
I encountered in developing each of the 
programs. I think PC-Metric could 
potentially be a very useful software 
development tool. A great deal depends, 
however, on the amount of effort you 
would be willing to invest in acquiring a 
degree of expertise with the metrics. 

PC-Metric costs $99. It runs on an 
IBM PC or compatible with 256 Kbytes 
of memory, 5%-inch disk drive, and MS- 
DOS 2.1 or later. Demonstration copies 
are available for $10. 
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Super PC-Kwik Disk Accelerator 

Sorel Reisman, California State University, Fullerton 


This package is fantastic. You don’t 
have to understand very much about 
extended, expanded, or conventional 
memory to use this program from Mul- 
tisoft and increase your computer’s per¬ 
formance by many factors. The increase 
you can achieve is largely a function of 
the amount of available memory in 
your computer—more is better—and 
the kind of application mix you typi¬ 
cally run. The more frequently your 
programs access disk (hard or floppy), 
the greater the increase in system per¬ 
formance. 

The manual is superb, explaining the 
principles of caching in straightforward 
English, if you care to read them. If 


you don’t care to, just type in one of 
the program’s example command lines. 
You’ll be amazed at your computer’s 
instant performance improvement on 
your very next disk access. One of the 
package’s options allows you to see the 
performance saving it provides, based 
on the number of disk accesses you 
avoid. Within 20 minutes of using the 
program, 1 added it to the autoexec file 
of my AT clone and my dual-floppy 
IBM PC Portable. 

The package is not hot-keyable, but 
when installed in conventional, 
expanded, or extended memory, can be 
easily uninstalled. Minimum and maxi¬ 
mum cache sizes are 


RAM Lord Version 2.IB 


Sorel Reisman, California State University, Fullerton 


RAM Lord, from Waterworks Soft¬ 
ware, is a RAM-resident program used 
to manage other RAM-resident pro¬ 
grams. Loaded into 25 Kbytes of con¬ 
ventional, expanded, or extended 
memory, it behaves like a quasi-operating 
system to help you manage the move¬ 
ment of other RAM-resident programs 
in and out of memory. 

To use RAM Lord, you must first 
load all your other RAM-resident pro¬ 
grams; you then load RAM Lord. Hot¬ 
key invocation of RAM Lord allows 
you to selectively load or remove the 
other RAM-resident programs from 
memory if you need to. While all this 
doesn’t sound like a big deal, your abil¬ 
ity to perform these functions from 
within a “super program” does turn 
out to be a real convenience. 

Installation of RAM Lord is a little 
tricky and requires you to use some 


common sense. The documentation is 
not always as precise as it should be, 
but the user interface of the program 
itself is helpful. Another problem with 
the 38-page manual (10 more pages are 
dedicated to a highly editorialized 
description of the technology) is that it 
does not explain error messages gener¬ 
ated by the program. 

Another of the program’s interesting 
features is an effective hot-keyable and 
easy-to-use cut and paste feature for 
text. I successfully used this feature to 
cut and paste text between applications 
and even RAM-resident programs. 

RAM Lord offers better than mar¬ 
ginal utility and is worth its price of 
$99.95. I intend to keep it installed for 
the foreseeable future. 
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Memory type Minimum Maximum 

Conventional 48K 512K 

Expanded 48K 1072K 

Extended 32K 1024K 

Super PC-Kwik requires DOS 2.0 or 
later and 14 Kbytes of RAM. It runs on 
floppy or hard disk-based IBM PC-type 
computers and compatibles. Multisoft 
successfully tested Super PC-Kwik on 
the Compaq 386 with the cache installed 
in conventional, expanded, and 
extended memory. 

Because Super PC-Kwik was designed 
to support IBM personal computers and 
100-percent compatible computers, it 
does not support the TI Professional 
computer or the Tandy 2000. While it 
does support the AT&T 6300 and 6300 
Plus, it does not support the extended 
memory available on the 6300 Plus. 
Lotus/Intel/Microsoft expanded mem¬ 
ory is supported on these machines. 

Multisoft successfully tested Super 
PC-Kwik with the following partition¬ 
ing software: 

• IBM DOS 3.3 Fdisk 

• Disk Manager (Version 3.0) from 
Ontrack Computer Systems 

• Extend (Version 2.0) from B & F 
Software 

• SpeedStor II (Version 4.0) from 
Storage Dimensions 

• Golden Bow Vfeature Deluxe Ver¬ 
sion 2.32 

• Priam ID/ED Software Release 
3.22 

Super PC-Kwik costs $79.95. If you 
are not using a cache right now, you 
ought to see if this package supports 
your system. If it does, get it for your 
PC—Kwik! 
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NEW PRODUCTS 


Prime targets systems DEC offers new family of mid-range VAX systems 

solutions 


Prime Computer has announced 
Prime Design, a 3D modeling system, 
and Prime Control, an engineering proj¬ 
ect control software system. 

Prime Design integrates solids, sur¬ 
face, and wireframe modeling. The pro¬ 
gram features a common database for 
testing of designs and for interfacing to 
machine tools. The software runs on the 
PXCL family of engineering graphics 
workstations. 

A typical entry-level system costing 
$79,900 includes a PXCL 5500 worksta¬ 
tion with a 5-MIPS processor, a 
floating-point chip, 24-color bit planes, 
12 Mbytes of memory, 340 Mbytes of 
disk capacity, the Unix System V oper¬ 
ating system, and the Prime De¬ 
sign/Modeler module. 

A typical high-performance package 
costing $104,900 includes a PXCL 5500 
workstation with a 10-MIPS processor, 
a floating-point chip, 24-color bit 
planes, 12 Mbytes of memory, 340 
Mbytes of disk capacity, a 24-bit Z- 
buffer, the Unix System V operating 
system, and the Prime Design/Modeler 
module. 

The Prime Design Detailer module 
costs $7,500. 

Prime Control works from a common 
Oracle database to define and automate 
information flow while it controls 
access to designs and the authority to 
make changes, according to the com¬ 
pany. Authorized changes impel the 
program to update related parts draw¬ 
ings and notify users working with 
those parts. 

Prime Control includes a Central 
Data Manager subsystem running on 
Prime’s 50 Series superminicomputer 
and Local Data Manager subsystems 
running on engineering workstations or 
other 50 Series systems. A Prime Con¬ 
trol LDM is embedded in each license 
of Prime Design. The Prime Control 
CDM uses an Oracle-based relational 
database. 

The Prime Control CDM costs from 
$23,900 to $75,000 depending on system 
configuration. LDMs cost from $900 to 
$3,800. 


Digital Equipment has announced the 
VAX 6200 Series, which the company 
says combines symmetric multiproces¬ 
sing with the VAXBI bus and CMOS 
technology. The series is based on the 
single-processor VAX 6210 and includes 
the dual-processor VAX 6220, three- 
processor VAX 6230, and four- 
processor VAX 6240. Prices range from 
$131,600 to $653,200 according to con¬ 
figuration. The series runs VMS V.5. 

DEC also announced a preconfigured 
entry-level VAXcluster system, based 
on two VAX 6210 systems, priced from 


Prime Computer has announced two 
more models in its multiuser, 20-MHz, 
80386-based supermicrocomputer 
family. The Prime EXL 320 and EXL 
325 reportedly increase performance by 
up to 25 percent and 56 percent, respec¬ 
tively, over the EXL 316 system. They 
support from 16 to 48 users. 

The EXL supermicrocomputers use 
Prime’s implementation of AT&T’s 
Unix system V.3 operating system. The 
EXL can run Unix and MS-DOS pro¬ 
grams concurrently, as well as Pick 
software. 

A basic configuration EXL 320 
includes 4 Mbytes of memory, 90 
Mbytes of formatted disk storage, a 


$479,100. Upgrade packages for the 
6200 Series range in price from 
$100,200 to $173,500. 

According to the company, the VAX 
6200 Series can serve as a company¬ 
wide system, department-level host 
computer, or central computing 
resource for a workgroup. In VAX¬ 
cluster environments, it can serve as the 
boot node, file server, or compute 
server with DEC’S Local Area VAX¬ 
cluster Phase II software. 
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60-Mbyte cartridge tape, an SCSI . 
disk/tape controller, and the operating 
system. Prices start at $25,900, with 
maintenance from $137 per month. 

A basic configuration EXL 325 
includes 8 Mbytes of memory, 258 
Mbytes of formatted disk storage, a 
60-Mbyte cartridge tape, an SCSI 
disk/tape controller, and the operating 
system. Prices start at $45,900, with 
maintenance from $174 per month. 

Configuration options offer up to 16 
Mbytes of memory, 114 asynchronous 
connections, and more than a gigabyte 
of disk storage. 



New supermicros out from Prime 


Prime Design: Reader Service 30 The Prime EXL 316, 320, and 325 (above) attain processing speeds up to 3.2, 4.0, 
PrimeControl: Reader Service 31 and 5.0 MIPS, respectively, and operate in Unix, MS-DOS, and Pick environments. 
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Vaccine claims to protect PC health 


Foundation Ware has announced a 
software program called Vaccine that 
reportedly provides data protection, 
data security, system checks, system 
enhancements, and data recovery func¬ 
tions for personal computers. Accord¬ 
ing to the company, the program helps 
prevent unintentional data loss caused 
by user mishaps or ignorance, and 
intentional data loss caused by mali¬ 
cious, data-destructive software. 

Vaccine consists of six modules: Sur¬ 
veillance, Bomb Shelter, Quality Assur¬ 
ance, Run-Time Quality Assurance, 
Installation and System Check-Up, and 
Critical Disk. 

The memory-resident Surveillance 
Module reportedly protects the system 
against anything that might write to the 
hard disk using unsafe or non-DOS 
methods. Before any data is destroyed, 
Vaccine interrupts the process and quer¬ 
ies the user. 

In the Bomb Shelter Module, the Sur¬ 
veillance Module and file protection are 
still active, but the hard disk is electron¬ 
ically removed from the system. You 
would activate this module if you sus¬ 
pected new software to be potentially 
damaging. 

The Quality Assurance Module 
checks each executable file and most 
other files that normally don’t change 
during system operation. Each time you 
start your system and every time you or 
a program loads or runs those files, 
Vaccine checks to be sure they meet 
original specifications. 

The Run-Time Quality Assurance 
Module checks software files before 
they are loaded. 

The Installation and System Check¬ 
up Module reputedly prevents the trans¬ 
fer of and infection by virus software. 
Vaccine checks the hard disk upon 
installation for appropriate use of sub¬ 
directories, multiple copies of the same 
software, and mixed versions of DOS 
files. It checks the Config.sys and 
Autoexec.bat files for appropriate sys¬ 
tem variables and setup parameters, 
and resolves conflicts or instructs the 
user on how to fix the problem. It also 
invokes the safety features available in 
DOS. 

The Critical Disk Module, according 
to the company, puts your system back 
together should you lose data. On 
installation, Vaccine creates a critical 
disk that matches the characteristics of 
your computer and its data structure. 
When placed in the A: drive, the critical 
disk allows the computer to boot nor¬ 
mally and will restore erased, damaged, 


formatted, or contaminated files on the 
hard disk. 

A corporate version of Vaccine 
reportedly enables a system operator to 
allow certain software on a system and 
to disallow all other software. 

The first version of Vaccine will not 
include the Surveillance Module, but 


The National Bulletin Board Society 
has developed a computer virus testing 
system to simulate viral attacks on IBM 
PCs. The benign pseudo-virus, called 
Universal Viral Simulator, reportedly 
uses all known techniques found in live 
viruses to infect and replicate in host 
systems. It is based on analyses of live 
viruses submitted to the BBS Society. 

According to the society, the simula¬ 
tor is meant to act as a testing and 
verification mechanism for antiviral 
systems under development. The viral 


LAN manages images stored 

Bell & Howell has announced the 
Image Search Plus LAN, a local area 
network for managing document 
images stored on optical disks. Accord¬ 
ing to the company, the product is iden¬ 
tical in operation to the single-user 
Image Search Plus system. The LAN 
system supports up to 16 workstations 
using Image Search software. 

Documents are digitized with the sys- 


Cygnet Systems claims that its new 
system, the Series 5000 Jukebox, 
exchanges disks in less than four 
seconds. The Series 5000 supports 
5X-inch drives. It specifically supports 
drives and media that conform to the 
ISO standard form factor and format, 
such as Fujitsu, Hitachi, Laserdrive, 
LMSI, Mitsubishi, Pioneer, and 
Toshiba. It also accommodates many 
non-ISO conforming drives, such as 
ISI, IBM, and Matsushita, according to 
the company. 

The Series 5000 Jukebox supports 
one or two drives in addition to one or 
two auxiliary drives that can be manu¬ 
ally loaded and unloaded. The system 


the second version will include all six 
modules. The second version will be 
supplied to all owners of the first ver¬ 
sion free of charge except for a shipping 
and handling fee. 

Vaccine costs $92. 
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simulator is executed after any antiviral 
systems have been loaded and activated. 
Each time the antiviral system blocks it, 
it displays a message naming the repli¬ 
cation attempt technique and its failure. 
If the simulator succeeds in “infecting” 
the system, it identifies the procedure 
used. 

The Universal Viral Simulator is 
available from the National BBS Soci¬ 
ety for $79.95. 
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on optical disks 

tern’s Copiscan scanner and stored on 
optical disks managed by the system’s 
image server. Key information can be 
entered manually or downloaded auto¬ 
matically. The index information is 
stored in the system’s record server. 

The LAN supports up to six 5X-inch 
or 12-inch drives. 
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accommodates 26 to 30 optical disk car¬ 
tridges and provides up to 31 Gbytes of 
storage. It comes with either an SCSI or 
RS-232-C interface to the host com¬ 
puter. Up to three units can be con¬ 
figured in a 19-inch rack. 

Cygnet’s Series 1800 12-inch expand¬ 
able jukeboxes and Jukebox Manage¬ 
ment Interface System software are 
compatible with the new series. 

The Series 5000 Jukebox has an OEM 
single-unit price of $14,500 without 
drive and media. Evaluation shipments 
are scheduled for July 1988 and produc¬ 
tion quantities, for the fourth quarter. 
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System simulates viral attacks on PCs 


Optical jukebox exchanges disks in less than 4 seconds 
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Masscomp computer family DEC enters WORM market 


Masscomp has announced the 6000 
Family of real-time computers based on 
the Motorola MC68030. The new sys¬ 
tems run RTU, the company’s real-time 
implementation of the Unix operating 
system. 

The 6000 Family consists of four 
groups: the MC6300, MC6400, 

MC6600, and MC6700 in configura¬ 
tions ranging from seven-slot pedestal 
to 30-slot cabinet systems. They support 
a binary-compatible, multiple-processor 
architecture; multiple floating-point 
and vector accelerators; multiple 
graphics seats, and optional data acqui¬ 
sition subsystems. 

The MC6300 system is a seven-slot 
pedestal of 9U Eurocard MVEbus mod¬ 
ules. The CPU is configured with one 
or two 25-MHz MC68030s. The system 
has one or two MC68882 floating-point 
coprocessors, one or two optional 
floating-point accelerators, 8 Mbytes of 
parity memory, an SCSI peripheral 
interface, an Ethernet controller, and 
four RS-232-C serial communications 
ports. Prices start at $24,900. 

The MC6400 system is a rack-mount 
configuration with six 9U VMEbus slots 
and six 6U VMEbus slots. It can sup¬ 
port two CPUs with shared cache, two 
floating-point coprocessors, two 
optional floating-point accelerators, 
parity memory, SCSI interface, Ether¬ 
net controller, and serial communica¬ 
tions ports. Additional slots are 
available. Prices begin at $28,900. 

The MC6600 comes in either pedestal 
or rack-mount configurations with 15 
slots. It supports up to three CPUs, 
each CPU supporting one MC68882, 
one optional floating-point accelerator, 
and one 14-Mflop vector accelerator. 
Each MC6600 supports up to three 
Multibus I/O channels, one or two 
optional VMEbus modules, and one or 
two Std + Bus data acquisition buses. 
Prices range from $42,500 to $77,900. 

The MC6700 comes in a 30-slot 
enclosure and supports up to five 
CPUs, each with its own cache, 
MC68882, and optional floating-point 
accelerator. It reputedly achieves up to 
56 Mflops using four vector accelera¬ 
tors. It suuports up to four Multibus 
I/O subsystems, two VMEbus I/O sub¬ 
systems, and two Std + Bus data acqui¬ 
sition subsystems. Prices range from 
$59,000 to $120,000. 

The MC6300/MC6400 CPU module 
is also available as a single-board com¬ 
puter, with prices starting around 
$ 10 , 000 . 
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Digital Equipment has entered the 
write-once, read-many times optical 
storage market with its RV20 sub¬ 
system. The RV20 works with VAX 
computers incorporating VAXBI-bus 
and Q-bus I/O structures, according to 
DEC. The laser-based subsystem 
reportedly allows users to store up to 
two gigabytes of data on a single 
12-inch optical disk. 

The company claims average access 
times between 150 and 250 ms. The 
RV20 also features specialized tape 
emulation, permitting its integration 
into applications designed for VAX 
computers that use tape drives. 

Prices for the RV20 subsystem start 
at $30,000 with a one-year warranty. 


Additional slave drives cost $25,000. 
Cartridges for RV20 drives cost $400. 

The company offers Storage Library 
System to manage tape and optical disk 
systems and their files. SLS functions 
include media and file catalog manage¬ 
ment, report generation, file archiving, 
and system management, according to 
the company. SLS runs on VAX sys¬ 
tems using Version 4.6 or higher of the 
VMS operating system. The software is 
licensed according to the system and 
number of users. Prices start around 
$500, but a typical SLS license would 
cost $10,000. 
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Lab computer has real-time Unix, 24 slots 


Masscomp has announced the SLS 
5550, one of the company’s Scientific 
Laboratory Systems. According to 
Masscomp, the system features one mil¬ 
lion samples-per-second data acquisi¬ 
tion and analysis, 12-bit A/D, 330,000 
samples-per-second throughput to disk, 
and nine Std + Bus slots for multiple 
data acquisition modules. 

The basic SLS 5550 includes a 
142-Mbyte ESDI Winchester disk and 
Masscomp’s graphics processor. Its 15 
system bus slots permit the addition of 
vector and floating-point accelerators, 


tape and disk systems, and graphics 
devices. 

The Scientific Laboratory Systems 
run a real-time Unix operating system 
and include Laboratory Workbench 
software. 

The SLS 5550 uses the Motorola 
MC68020 CPU and MC68881 math 
coprocessor and is based on Mass- 
comp’s Triple Bus architecture. It costs 
$27,500, including hardware and 
software. 
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Workstation aids MMIC design 


EEsof has announced the MMIC 
Design Workstation for microwave/RF 
designers. The turnkey system report¬ 
edly allows users to perform schematic 
capture, linear and nonlinear simula¬ 
tion, circuit-driven and custom layout, 
and design verification. 

System software combines a graphics 
editor from SDA Systems’ Design 
Framework with EEsof’s simulators 
(Libra, Touchstone, Microwave SPICE) 
and layout processor MiCAD. The pro¬ 
grams are integrated on Apollo DN 
3000/4000 and Sun-3 computer 
platforms. 

Prices range from $35,000 to 
$150,000 according to configurations 
and options. The price includes one 
year of software and hardware support, 
including installation, telephone sup¬ 
port, upgrades, and training. 
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EEsof’s MMIC Design Workstation, 
shown here on an Apollo Domain plat¬ 
form, facilitates the MMIC designer’s 
work. 
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Imaging workstation is based on Mac II 


Perceptics has announced the NuVi- 
sion image processing workstation, 
which combines a real-time image 
processor with the Apple Macintosh II. 

NuVision features an integral digital 
signal processor on each image memory 
for parallel processing of multiplane 
images; frame grabs of 1,024 x 1,024 
monochrome, RBG true color, and ste¬ 
reo pair images, reportedly in .3 second; 
1,280 x 1,024 24-bit color display; a 
pixel processor for real-time video 
arithmetic/logic and histogram compu¬ 
tations; flexible region-of-interest pro¬ 
cessing; and software for basic display, 
spatial Fourier, geometrical, and mor¬ 
phological processing, including inter¬ 


polated zoom, convolution, frequency 
filtering, warping, and blob statistics. 

The DSP is a Texas Instruments 
TMS320C25 running at 40 MHz. The 
system has four asynchronous RS-232 
serial lines and 16 bits of programmable 
I/O. 

A user-programmable Motorola 
68020 or 68881 image coprocessor is 
optional. 

A basic NuVision system, without the 
Macintosh II, costs about $17,000. A 
complete NuVision workstation (NuVi¬ 
sion plus Macintosh II plus monitor) 
costs about $26,000. 
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Entry-level models join fault-tolerant systems 


Stratus Computer has expanded its 
XA2000 Continuous Processing Sys¬ 
tems family of fault-tolerant on-line 
processors with two entry-level com¬ 
puters, the XA2000 Models 50 and 70. 

The new models are compatible with 
other Stratus computers, according to 
the company. They connect with other 
Stratus systems through StrataLink and 
StrataNet. The Model 50 and 70 CPU 
boards incorporate Motorola 68000 
family microprocessors. 

The Model 50 comes in a 10-slot, 
34-inch cabinet, while the Model 70 
comes in a 10-slot, 54-inch cabinet. The 
Model 50-T comes in a 54-inch cabinet 


for expansion to the Model 70. 

The new models incorporate Stratus’ 
new Input/Output Subsystem, an intel¬ 
ligent I/O subsystem that increases the 
number and variety of communications 
interfaces available. The IOP also pro¬ 
vides a controller for mass storage func¬ 
tions on the Models 50 and 70. 

The XA2000 Models 50 and 70 come 
in a variety of configurations with disk, 
tape, memory, and communications 
expansion options. Entry-level pricing 
starts at $79,000 for the Model 50, 
$84,000 for the Model 50-T, and 
$110,000 for the Model 70. 
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Stratus Computer’s XA2000 family of on-line, fault-tolerant processors has two 
new entry-level members, Model 50 (left) and Model 70 (right). Prices start at 


New supermicros 
implement Unix, Xenix 

The Thoroughbred Division of Con¬ 
cept Omega has added two 32-bit Intel 
80386-based Unix and Xenix computers 
to its family of supermicrocomputers. 
The TSU-386 and TSX-386 are avail¬ 
able to value-added resellers. 

The TSU-386 with AT&T’s Unix 
5V3.1 operating system, Thoroughbred 
Basic, and Thoroughbred Word ranges 
in price from $9,595 to $20,895 depend¬ 
ing on the number of users. 

The TSX-386 with the SCO Xenix 
System V operating system, Thorough¬ 
bred Basic, and Thoroughbred Word 
ranges in price from $7,995 to $14,495. 

The TSU-386 supports up to 24 users 
and the TSX-386, up to 16. Both sys¬ 
tems will be shipped to VARs with soft¬ 
ware loaded on the hard disk, according 
to the company. Both systems have 
optional storage and communications 
peripherals available. 
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Intel offers embedded 
processor, peripheral chip 

Intel has announced the Intel 376 
embedded processor, a 32-bit derivative 
of the Intel 386 microprocessor architec¬ 
ture. According to the company, 
designers can use any 386-based PC to 
develop and debug software for 376 
processor systems. The 376 processor 
offers an upgrade for 80186 designs. 

The company has also introduced the 
82370, a multifunction peripheral 
device and companion chip to the 376 
processor. The 82370 integrates eight 
DMA channels, 15 interrupts, four 
16-bit timer/counters, DRAM refresh, 
and wait-state generation. 

Sampling of the 376 processor and 
82370 peripheral is scheduled for June 
1988, with production in the fourth 
quarter. Both chips come in plastic, 
100-pin surface-mount packages. The 
376 processor also comes in an 88-lead 
pin grid array and the 82370, in a 
132-lead PGA. The 376 processor costs 
$99 in 100-unit volumes and the 82370, 
$57. 


376: Reader Service 47 
82370: Reader Service 48 
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The Unix-based Tandem LXN 402 features mirrored disks and auto restart soft¬ 
ware. It supports up to 32 users. 


Tandem expands Unix-based LXN family 


Tandem Computers has added the 
LXN 402 to its family of Unix-based, 
32-bit, multiuser LXN systems. 

The LXN 402 supports up to 32 
users. Based on the Motorola 68020 
operating at 20 MHz, it comes with an 
80-Mbyte hard disk, a 10-port serial 
communication controller, two mega¬ 
bytes of memory, a 60-Mbyte X-inch 
cartridge tape drive, and a 5^-inch disk 
drive. Three slots are available for 


option boards, and memory is expandable 
to 16 Mbytes. Disk storage is expandable 
to one gigabyte. 

An MC68881 floating-point 
coprocessor is optional. Also optional is 
an uninterruptible power supply. 

Single units cost $25,500. A network 
unit price, based on the purchase of 25 
to 39 systems, is $19,380. 

Reader Service 49 


Multiprocessor claims data-flow-based architecture 


Pacific Cyber/Metrix Corp. has 
announced a multiprocessor system 
called Hyperflo, which the company 
claims implements a new architecture 
based on data-flow principles and mul¬ 
tiple instruction stream, multiple data 
stream design. 

According to the company, Hyperflo 
features performance of more than 250 
million instructions per second in a sin¬ 
gle VMEbus card cage, multiple proces¬ 
sors, processor independence, 
incremental performance enhancement 
through the addition of more proces¬ 
sors, fault tolerance, multitasking, 
VMEbus implementation, easy 
upgrades to prevent obsolescence, sup¬ 
port of Unix and OS-9, and a runtime 
operating system carried in ROM on 
every board. 

A Hyperflo system can be imple¬ 
mented with a minimum of four VME¬ 
bus modules: one MPU-1 


Quad-Processor Module, one SRB-2 
System Resource Module, one GMC-1 
Memory Controller, and one GMM-1 
Memory Module. This basic module set 
provides four 20-MHz 68020 
microprocessors, two 68881 floating¬ 
point processors, four megabytes of 
memory (up to 16 Mbytes), Hyperflo’s 
ROM-based FLOS operating system, 
and all hardware functions required to 
implement the Hyperflo system. 

Application software can be written 
in C, Ada, and the native assembler for 
each supported processor type. Unix 
and OS-9 are supported as development 
environments. The only runtime operat¬ 
ing system required is the distributed 
FLOS operating system. 

The basic Hyperflo system starts at 
$20,300. Shipments are scheduled for 
June. 
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Optical system 
manages documents 

The Docutron 2000 from 3M is a 
document management system first 
introduced in 1986. It consists of an 
optical disk drive, scanner, display 
screen, printer, keyboard, and elec¬ 
tronic controls. The base system sup¬ 
ports up to 15 remote terminals. 

Recent enhancements include added 
software capabilities and increased disk 
capacity. 

The new multifile search capability 
means that users can search for a file 
that occupies many disks. This is possi¬ 
ble because the system now treats a 
multidisk application as one file, and 
tells the user which disk(s) to insert to 
look at the file. 

Disk capacity has increased from 
30,000 images average per side to 
40,000 images per side, for a total of 
3.6 gigabytes per disk. The price of the 
disks has not changed, remaining $595 
each. 

The basic Docutron 2000 system costs 

$ 100 , 000 . 

Reader Service 51 

Foundation supports 
software development cycle 

Arthur Andersen & Co. has 
announced Foundation, which the com¬ 
pany calls an integrated software devel¬ 
opment environment designed to 
support and automate the life cycle of 
application software development. The 
product consists of three integrated 
modules: Method/1, Design/1, and 
Install/1. 

Method/1 is a PC-based, on-line, 
life-cycle methodology that supports 
information planning, custom and iter¬ 
ative development, packaged systems 
implementation, and production sys¬ 
tems support, according to the 
company. 

Design/1 is a PC-LAN-based set of 
software tools to automate systems 
design tasks. A mouse controls the 
menu-driven module. 

Install/1 is the mainframe environ¬ 
ment for implementation and support 
of applications based on CICS, Cobol 
II, and DB2. It contains a data reposi¬ 
tory built on IBM’s DB2 relational 
database system. 

Contact the company for pricing and 
more information on system 
requirements. 

Reader Service 52 
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1C Announcements 


Company, Model, Function Comments R.S. No. 


Advanced Micro Devices 

PALC18U8Q 

PAL family 


Analog Devices 

ADSP-2101/2102 

DSP 


Chips and Technologies 
82C425 

LCD/CRT controller 


Intel 

27F256/28F256, 27F64 
Flash memories 


Motorola 
68000 family 
New speed versions 

Motorola 
MC68HC11F1 
Memory control unit 


National Semiconductor 
NMC98C10/20/40 
EEPROMs 


Signetics 
PLC20V8 Series 
PAL devices 


Sony 

ECL logic family 
ECL devices 

Texas Instruments 

SN74ALS2232/2233/2234 

FIFOs 


Texas Instruments 
TGC100 Series 
Gate arrays 


Toshiba America 
TC514266AP/AJ/AZ, 
TC514268AP/AJ/AZ 
DRAMs 

Toshiba America 
TC511000AP/AJ/AZ, 
TC511001AP/AJ/AZ, 
TC511002AP/AJ/AZ 
DRAMs 


A 20-pin, universal programmable-array-logic family featuring 10 dedicated input lines and 120 
a macrocell configurable in one of eight combinatorial or registered options. Comes in 
25-ns and 35-ns propagation delay versions, in plastic and ceramic windowed DIPs. Cost: 

(1,000s) $4 (24 ns), $2.75 (35 ns). 

Microcomputer versions of the ADSP-2100A digital signal processor. ADSP-2101 is an all- 121 
RAM version; ADSP-2102 has masked ROM program memory. Both feature on-chip 
memory, an external 14-bit address, and 24-bit data bus. Packaged in a 68-pin PLCC or 
PGA. Sampling in fourth quarter 1988. Cost: starts at $54 (1,000s). 

An LCD/CRT controller compatible with IBM’s CGA display specifications. Designed for 122 
laptop computers. Includes SmartMap for legible color applications on monochrome dis¬ 
plays. Supports two 8K x 8 SRAMs and two fonts in a third SRAM. Comes in a 100-pin 
flat pack. Cost: $16.50 (100s). 

A line of 256- and 64-Kbit, nonvolatile, read/write flash memories. Features the Quick- 123 
Erase and Quick-Pulse Programming algorithms. The 28-pin 27F64 is a direct socket 
replacement for 64-Kbit EPROMs. The 27F256 has 28 pins and the 28F256 has 32. Cost: 

(10,000s) $19.90 for 250-ns 27F256 and 28F256, $8 for 250-ns 27F64. 

New versions of 68000 family microprocessors: a 33-MHz 68020, a 16-MHz 68000, and a 124 
16-MHz 68HCOOO. Cost: (quantities of 100-499) $571 for 68020; $34.45 for 68HC000 in a 
plastic DIP; $18.90 for 68000. Also, $485 for 25-MHz 68030. 

A member of the MC68HC11 family, with 68 pins and a nonmultiplexed bus. Features four 125 
programmable chip selects with clock-stretching capability. A ROMless device with on-chip 
memory of 512 bytes of EEPROM and 1 Kbyte of SRAM. Samples late in third quarter 
1988. No price given. 

EEPROMs in 1-, 2-, and 4-Kbyte configurations. Fit in 300-ml, 18-pin plastic DIP. Feature 126 
automatic erase-before-write and data polling. Compatible with SRAMs. Cost: (100s) 

$7.50 for NMC98C10 (128 X 8), $9 for NMC98C20 (256 X 8), $10.50 for NMC98C40 
(512x8). 

EPROM-based programmable-array-logic devices. Two half-power and two quarter-power 127 
devices operating at 13.3 MHz or 18.1 MHz synchronously. One-time programmable ver¬ 
sions in 24-pin plastic DIP or 28-pin PLCC, reprogrammable versions in 24-pin hermetic 
DIP. Cost: (100s) $6.83-$10.42 (quarter-power), $5.42-$8.83 (half-power). 

First release—24 products—of emitter-coupled logic devices in Sony’s ECL 3 Process- 128 

based family. Speeds up to 4 GHz with power below one watt. Most come in a 24-lead flat 
pack. Customized functions available in July 1988. Cost: $40 to $150 (OEMs). 

Three 64-word x 8-bit (2232) and 64-word x 9-bit (2233 and 2234) FIFOs operating at 40 129 

MHz with a 30-ns maximum fallthrough time. Cascadable, with the 2234 also cascadable in 
depth. Come in 28-pin plastic DIPs, with PLCCs planned. Cost: $18.77 (1,000s) for 2232 
and 2233; 2234 available for sampling. 

One-frm CMOS gate arrays. Initial release of three arrays ranging from 2,300-8,896 gates 130 
with 84-142 I/Os. Feature an AC-performance test structure in each base array. Packaging 
from 28-pin DIPs to 84-pin PLCCs; options up to 144 pins. Cost: $12.06 (10,000s) for 
68-pin PLCC, plus $25,000 engineering charge. 

One-Mbit DRAMs with write-per-bit for selective data masking. Organized as 256K x4 131 
with fast page (TC514266A) and static-column (TC514268A) modes. Access times of 70 ns, 

80 ns, or 100 ns. Come in 20-pin plastic DIP (P suffix), plastic small-outline J-lead package 
(J suffix), and plastic ZIP (Z suffix). No prices given. 

One-Mbit DRAMS with access times to 70 ns. Organized as 1-Mbit x4 with fast page 132 

(TC511000A), nibble (TC511001 A), and static-column (TC511002A) modes. Available in 
18-pin plastic DIP (P suffix), plastic small-outline J-lead package (J suffix), and plastic 
ZIP (Z suffix). No prices given. 
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Microsystem Announcements 


Company, Model, Function Comments R.S. No. 


American Micronics 
Elephant 386 

386 board 

An 80386-based system board for IBM PC AT-type machines. Uses Chips & Technologies 135 

chip set and AMI BIOS. Optional Intel 80387 math coprocessor. Sockets for 2 Mbytes of 

RAM with expansion up to 10 Mbytes. Cost: $1,949 (16 MHz), $2,592 (20 MHz), $3,120 
(24 MHz). 

Arcom Control Systems 
SG84 

STEbus graphics board 

A single-Eurocard STEbus graphics board with 640 x 400-pixel resolution and 16 or 256 136 

colors from a palette of 262,144. Uses Hitachi’s 63484 IC, which combines a display con¬ 
troller with a graphics processor. Has 256 Kbytes of RAM. Cost: £485. 

Austek Microsystems 

Cobra 

Cache system board 

A PC AT cache system board design and documentation package for system designers. 137 

Incorporates a 20-MHz 80386 CPU, 32 Kbytes of cache memory using the A38152 

Microcache controller chip and eight expansion slots. Kit includes a manual, logic 
schematics, and PAL equations. Cost: $3,900. 

Boca Research 

Bocaram 50/60 

Memory board 

A Micro Channel architecture memory board for the IBM PS/2. Provides OS/2 memory 138 

and emulated LIM EMS. Comes in 1- and 2-Mbyte configurations, expandable to 4 Mbytes 
per board. Includes menu-driven installation and a diagnostics package. Cost: $645 (1 

Mbyte), $995 (2 Mbytes), $1,695 (4 Mbytes). 

Computer Peripherals 

386 Memoire 

Memory board 

A 32-bit memory expansion board for the Compaq Deskpro 386. Supports up to 2 Mbytes 139 

of high-speed, parity-checked memory. Comes with 1 Mbyte on-board and is socketed for 
upgrades. Cost: $695 (1 Mbyte) to $1,145 (2 Mbytes). 

MegaTape 

MT-1500, GT-88 

Backup drives 

MT-1500 uses the MegaTape standard cartridge for formatted capacity of 1.2 Gbytes and a 140 
data transfer rate of 764 Kbytes/s. GT-88 uses an 8-mm cartridge for a capacity of 2 

Gbytes and a data transfer rate of 246 Kbytes/s. Subsystems available. Cost: $19,500 for 

MT-1500 high-performance, $16,500 for MT-1500 medium-performance, $7,950 for 

GT-88. 

Procom Technology 
PXF1200 

Floppy disk drive 

A 1.2-Mbyte, external, 5/-inch floppy disk drive for IBM PS/2 computers. Features a data 141 
transfer rate up to 500 Kbits/s and 3-ms data access time. Incorporates a controller and 
reads, writes, and formats 360-Kbyte and 1.2-Mbyte disks. Cost: $450. 

Siemens 

MegaFile 4410 ESDI, 

4420 SCSI 

Winchester disk drives 

Two MegaFile 380-Mbyte Winchester disk drives with data transfer rates of 15 Mbit/s and 142 
access times of 18 ms. The 4420 Small Computer Systems Interface drive operates in syn¬ 
chronous mode with burst rates up to 4 Mbytes/s. Cost: $1,895 (100s). 

Square D 

Model 600 communicates with up to 15 peer processors at 10 Mbaud. It has an internal 143 


Sy/Max Models 400 and 600 math coprocessor and an extended instruction set. Model 400 has the same instruction set 


Programmable controllers 

and two integral communication ports for ASCII communications. No prices given. 

Storage Concepts 

Concept 41 

Winchester disk drive 

A Winchester disk drive subsystem with disk transfer rates of 18.6 Mbytes/s peak and 16 144 

Mbytes/s sustained. Features a 16-bit data bus with burst capacity of 20 Mbytes/s. Links 
to host processors through single-card host adapters. No price given. 

Systems SPS 

SPS-12 

Programmable controller 

A programmable controller supporting an Intel 8051, 8031, or 8751 microprocessor. Has 145 

40 input and 24 output signal lines and includes a real-time clock/calendar with 64 bytes of 
protected RAM, 8 Kbytes of on-board RAM, and interfaces for a printer, LCD, and 

RS-232. No price given. 

Tecmar 

MicroRAM update 

Memory board for OS/2 

A MicroRAM board that supports 8 Mbytes of memory under OS/2 while conforming to 146 

IBM conventions for Micro Channel and OS/2 protocols. Available in three models for 
memory and I/O expansion of PS/2 computers. No prices given. 

The Voice Connection 
IntroVoice VI 

Voice I/O system 

A half-size circuit board and software for voice I/O. Works with the IBM PC, XT, AT, or 147 
compatibles. Features voice recognition of 500 words and unlimited text-to-speech synthe¬ 
sis. Includes the circuit board, software and vocabularies, microphone, speaker, and man¬ 
ual. Cost: $865. 
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CONFERENCES 


Editor: Edmund L. Gallizzi, Computer Science Dept., Eckerd College, St. Petersburg, FL 33733; (813) 864-8272; Compmail, e.gallizzi 


‘Teaching innovation’ to be theme of first VLSI Education Conference 


The National Science Foundation will 
sponsor its initial VLSI Education Con¬ 
ference and Exposition August 24-26 in 
Santa Clara, California, featuring 
“Teaching Innovation in VLSI” as its 
theme. Paul Losleben of Stanford Uni¬ 
versity is serving as the general chair, 
and representatives of 14 leading 
universities are on the Steering Com¬ 
mittee. 

“After a decade of experience in 
VLSI education, where are all the 
chips?” Losleben asks. He said that 
over 500,000 printed circuit boards are 
designed each year in the US. 

“If this is a rough measure of the 
number of electronic products designed, 
then the 25,000 custom, semicustom, 
and application-specific integrated cir¬ 
cuit chips designed each year are an 
indication that only one in 20 products 
is using this advanced technology,” 
Losleben said. 

“With over 100 semiconductor foun¬ 
dries and over 150 computer-aided 
design companies competing for this 
business, the major limitation seems to 
be education. In fact, only one in 17 
related university departments is teach¬ 
ing the material.” 

The national need for more VLSI 
designers was the topic of a planning 
meeting held at the NSF last December. 
Thirty-three representatives of universi¬ 
ties and corporations met with govern¬ 
ment officials to discuss migration of 
VLSI materials into undergraduate cur¬ 
ricula and introduction of the data to 
more schools as possible solutions. 

The cost of teaching VLSI is a major 
deterrent, and the concept of a summer 
conference where university educators 
and industry representatives could get 
together was conceived as a first step 
toward solving the problem. 

Carver Mead of the California Insti¬ 
tute of Technology will deliver the key¬ 
note address. It was Mead, along with 
Lynn Conway of Xerox PARC, who 
shook up the semiconductor industry in 
the late 1970s with a radical new way of 
designing chips. 

Their Introduction to VLSI Systems 
has remained the textbook of choice for 
the past decade. Never content with 
conventional methods of design, Mead 
has recently concentrated his energies 


on a new text, Analog VLSI and Neural 
Systems. 

These new circuits mimic human- 
brain functions to potentially achieve 
capabilities exceeding those of super¬ 
computers. Whether in analog or digital 
design, the emphasis of the research and 



Carver Mead will be one of four ple¬ 
nary speakers at the IEEE Conference 
on Neural Networks July 24-27 in San 
Diego and will keynote the VLSI Edu¬ 
cation Conference, to be held August 
24-26 in Santa Clara, California. 


Eduardo Caianiello, John Caulfield, 
Carver Mead, and David Rumelhart 
will be the plenary speakers at the 
annual IEEE International Conference 
on Neural Networks July 24-27 in San 
Diego. 

Teuvo Kohonen of the Helsinki Uni¬ 
versity of Technology in Finland is the 
conference chair, and Bart Kosko of the 
University of Southern California is 
program committee chair. 

Rumelhart of the University of 
California at San Diego and Mead of 
the California Institute of Technology 
will speak July 24. Rumelhart’s topic is 
“Parallel Distributed Processing,” and 
Mead will focus on “Architectures for 
Neural Preprocessing.” 


educational community he helped form 
is innovation. 

As we look ahead to the next decade, 
dissemination of the emphasis on inno¬ 
vation throughout the university system 
is an encouraging sign in an otherwise 
economically troubled world, Losleben 
said. 

Training thousands of designers will 
not be easy, and the first day of the 
meeting is intended to provide informa¬ 
tion about how to get started. The pro¬ 
gram will include information on 
building a program from scratch, 
undergraduate program issues, regional 
centers that can provide help, national 
services available to educators, and 
government and industrial grant 
programs. 

On the second and third days, educa¬ 
tors and exhibitors will meet to discuss 
common interests. The educators will 
get hands-on experience with exhibitor 
products such as computer worksta¬ 
tions, CAD/CAE systems, instruments 
and test equipment, prototyping kits, 
laboratory equipment, and textbooks 
and course material. 

For information about the confer¬ 
ence, contact Paul Losleben, CIS 110, 
Stanford University, Stanford, CA 
94305, or call the conference office at 
(415) 329-0510. 


Caianiello and Caulfield are slated 
for July 25 addresses. Caianiello of 
Universita di Salerno in Italy will speak 
on “The First Years of Neurocomput¬ 
ing,” and Caulfield of the University of 
Alabama will talk on “Vistas in Optical 
Neurocomputer Design.” 

Ira Skurnick of DARPA will moder¬ 
ate a panel discussion on government 
funding July 26. 

Fourteen tutorials will precede the 
conference July 23. 

Additional information may be 
obtained by contacting Nomi Feldman, 
IEEE ICNN 88 Conference Secretariat, 
3770 Tansy St., San Diego, CA 92121, 
phone (619) 453-6222. 


Four to address plenary sessions at 
IEEE Neural Networks Conference 
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CALENDAR 


June 1988 


DAC 88, 25th ACM/IEEE Design 
Automation Conference, June 12-15, 
Anaheim, Calif. Contact Pat Pistilli, MP 
Associates, 7490 Clubhouse Rd., Suite 102, 
Boulder, CO 90301, phone (303) 530-4333. 

Computer Security Foundations Work- 
Ng? shop, June 12-15, Franconia, N.H. 
Contact Jonathan K. Millen, Mitre Corp., 
MS B325, Burlington Rd., Bedford, MA 
01730. 


ICC 88, International Conference on Com¬ 
munications (IEEE), June 12-15, Philadel¬ 
phia. Contact Gary Ridge, Bell of Pennsyl¬ 
vania, 15th Floor, 1 Pkwy., Philadelphia, 

PA 19102, phone (215) 466-8709; or ICC 88, 
c/o IEEE Office, Moore School of Electrical 
Engineering, Rm. 209, University of Penn¬ 
sylvania, Philadelphia, PA 19104, phone 
(215) 898-8106. 


Sixth IEEE European Workshop on 
Design for Testability, June 13-16, 
Arnitem, The Netherlands. Contact Thomas 
W. Williams, IBM Corp., 67A/021, PO Box 
1900, Boulder, CO 80301, phone (303) 
924-7692. 


ing (IFAC), June 14-17, Dresden, West 
Germany. Contact IFIP, 3 rue de Marche, 
CH-1204, Geneva, Switzerland. 

1988 Rochester Forth Conference on Pro¬ 
gramming Environments, June 14-18, Roch¬ 
ester, N.Y. Contact Lawrence P. Forsley, 
Institute for Applied Forth Research, 70 
Elmwood Ave., Rochester, NY 14611, phone 
(716) 328-6426. 

NECC 88, Ninth National Educational Com¬ 
puting Conference (ACM), June 15-17, 

Dallas. Contact NECC 88, International 
Council for Computers in Education, Uni¬ 
versity of Oregon, 1787 Agate St., Eugene, 
OR, 97403-9905, phone (503) 686-4414; or 
James L. Poirot, Computer Science Dept., 
North Texas State University, PO Box 
13886, Denton, TX 76203-3886, phone (817) 
565-2818. 

IEEE International Symposium on Informa¬ 
tion Theory, June 19-24, Kobe, Japan. Con¬ 
tact Shu Lin, Dept, of Electrical Engineer¬ 
ing, University of Flawaii at Manoa, Holmes 
Hall 483, 2540 Dole St., Honolulu, HI 
96822; or Suguru Arimoto, Faculty of 
Engineering Science, Osaka University, 
Toyonaka, Osaka 560, Japan. 


Conference Services Dept., Institution of 
Electrical Engineers, Savoy PL, London 
WC2R OBL, UK. 

Compass 88, Computer Assurance Confer¬ 
ence (IEEE), June 27-July 1, Gaithersburg, 
Md. Contact Compass 88, PO Box 5314, 
Rockville, MD 20851. 

Third International Conference on Data and 
Knowledge Bases, June 28-30, Jerusalem. 
Contact Databases Conference Secretariat, 
PO Box 29313, Tel Aviv 65121, Israel, phone 
(972)03-654-541. 

Westex 88, Third Expert Systems Conference 
(IEEE), June 28-30, Anaheim, Calif. Con¬ 
tact Westex 88, 8110 Airport Blvd., Los 
Angeles, CA 90045, phone (800) 262-4208 
(US) or (800) 421-6816 (California). 

Aegean Workshop on Computing, 

June 28-July 1, Corfu Island, Greece. 
Contact John Reif, Computer Science Dept., 
Duke University, Durham, NC 27705, phone 
(919) 684-3048. 


July 1988 


Fifth International Conference on Testing 
Computer Software (DPMA), June 13-16, 

Washington, DC. Contact William Hetzel, 
Software Quality Engineering, 3015 Hartley 
Rd., Suite 16, Jacksonville, FL 32217, phone 
(904) 268-8639; or US Professional Develop¬ 
ment Institute, 1734 Elton Rd., Suite 221, 
Silver Spring, MD 20903, phone (301) 
445-4400. 


£3^v Eighth International Conference on 
Distributed Computing Systems, June 
13-17, San Francisco. Contact Carl Davis, 
Dept, of Computer Science, University of 
Alabama, Huntsville, AL 35899, phone (205) 
895-6088. 


17th Mumps Users’ Group Meeting, June 
13-17, New Orleans. Contact Mumps Users’ 
Group, 4321 Hartwick Rd., Suite 510, Col¬ 
lege Park, MD 20740, phone (301) 779-6555. 

Third Ada Software Engineering Education 
and Training Symposium, June 13-17, Den¬ 
ver, Colo. Contact Catherine W. McDonald, 
Institute for Defense Analyses, 1801 N. 
Beauregard St., Alexandria, VA 22311, 
phone (703) 824-5531. 


Third Conference on Structure in 
vS? Complexity Theory, June 14-17, Wash¬ 
ington, DC. Contact Alan L. Selman, Col¬ 
lege of Computer Science, 161 CN, 360 
Huntington Ave., Boston, MA 02115, phone 
(617)437-8688. 


Prolomat 88, Seventh International Confer¬ 
ence on Software for Discrete Manufactur- 


1988 Summer Unix Technical Conference 
and Exhibition, June 20-24, San Francisco. 
Contact Usenix Assoc. Conference Office, 
PO Box 385, Sunset Beach, CA 90742, 
phone (213) 592-1381. 

SIGPlan 88 (ACM), June 20-24, Atlanta. 
Contact David Wise, Indiana University, 101 
Lindley Hall, Bloomington, IN 47405, phone 
(812)335-9770. 

International Conference on Private Switch¬ 
ing Systems and Networks (IEE), June 21- 

23, London. Contact Conference Services 
Dept., Institution of Electrical Engineers, 
Savoy PL, London WC2R OBL, UK. 

18th International Symposium on 
Fault-Tolerant Computing, June 
27-30, Tokyo. Contact Yasuo Komamiya, 
2-4-8 Kikuna, Kohoku-Ku, Yokohama 222, 
Japan, phone (81) 044-911-8181. 

Fifth International Conference on Dielectric 
Materials, Measurements, and Applications, 
June 27-30, Canterbury, England. Contact 


1988 International Conference on Supercom¬ 
puting (ACM, INRIA), July 4-8, Saint-Malo, 
France. Contact C.D. Polychronopoulos, 
Center for Supercomputing, University of 
Illinois, 104 S. Wright St., Urbana, IL 61801 
(in North and South America); W. Jalby, 
INRIA, BP 105, 78153 Le Chesnay Cedex, 
France (in Europe, Middle East, and Africa); 
or H. Terada, Dept, of Electronic Engineer¬ 
ing, Osaka University, Yamadaoka, 2-1 
Suita, Osaka, Japan 565 (in Japan and the 
Far East). 

Conference on the Role of Artificial Intelli¬ 
gence in Databases and Information Systems 
(IFIP), July 4-8, Canton, China. Contact 
Robert Meersman, Infolab, K.U. Brabant, 
Postbus 90153, NL-5000 Le Tilburg, The 
Netherlands, phone 31 (13) 662-430. 

Eighth International Conference in Com¬ 
puter Science, July 4-8, Santiago, Chile. 
Contact Alberto O. Mendelzon, CSRI, Uni¬ 
versity of Toronto, 10 King’s College Rd., 
Toronto, Canada M5S 1A4, phone (416) 
978-2952. 


^3^ Conferences that the Computer Society sponsors or participates in are indicated 
by the Computer Society logo; additional conference sponsors are listed in paren¬ 
theses. Other conferences of interest to our readers are also included. 


For inclusion in Call for Papers or Calendar, submit information six weeks before the 
month of publication (i.e., for the August 1988 issue, send information for receipt by 
June 15, 1988) to Calendar Editor, Computer , 10662 Los Vaqueros Cir., Los 
Alamitos, CA 90720. 
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£2^. Third Symposium on Logic in Com- 
*5*7 puler Science, July 5-8, Edinburgh, 
Scotland. Contact A.K. Chandra, IBM T.J. 
Watson Research Center, PO Box 218, 
Yorktown Heights, NY 10598, phone (914) 
945-1752. 


Second Conference on Software Engineering 
(IEE, BCS), July 11-15, Liverpool, England. 
Contact Conference Services, IEE, Savoy 
Place, London WC2R OBL, England, UK. 


CASE 88, Second International Work- 
v»7 shop on Computer-Aided Software 
Engineering (ACM), July 12-15, Cambridge, 
Mass. Contact Elliott Chikofsky or Pamela 
Meyer, CASE 88, c/o Index Technology 
Corp., One Main St., Cambridge, MA 
02142, phone (617) 494-8200, ext. 552 or 


12th IMACS World Congress on Scientific 
Computation, July 18-22, Paris. Contact 
Jean-Marc David, Laboratoires de Marcous- 
sis, Computer Science Division, Route de 
Nozay, 91460 Marcoussis, France. 

Z2N Second Workshop on Software Test- 
*5*7 ing, Verification, and Analysis, July 
19-21, Banff, Canada. Contact Lee White, 
Dept, of Computer Science, University of 
Alberta, Edmonton, Alberta, Canada T6G 
2H1, phone (403) 432-4589. 

PPEALS 88 (ACM), July 19-21, New 

Haven, Conn. Contact Assoc, of Computing 
Machinery, 11 W. 42nd St., New York, NY 
10036, phone (212) 869-7440. 

International Workshop on VLSI for Artifi¬ 
cial Intelligence, July 20-22, Oxford, 
England. Contact Jose G. Delgado-Frias or 
Will R. Moore, Dept, of Engineering 
Science, University of Oxford, Parks Rd., 
Oxford, OX1 3PJ, England, UK, phone (44) 
0865-273-188. 

ICNN 88, IEEE 1988 International Confer¬ 
ence on Neural Networks, July 24-27, San 
Diego, Calif. Contact Nomi Feldman, IEEE 
ICNN 88, 3770 Tansy St., San Diego, CA 
92121, phone (619) 453-6222. 

ECCE 88, European Conference on Com¬ 
puters and Education, July 24-29, Lausanne, 
Switzerland. Contact IFIP, 3 rue de Marche, 
CH-1204, Geneva, Switzerland. 

Summer Computer Simulation Conference 
(SCS), July 25-27, Seattle. Contact Society 
for Computer Simulation, PO Box 17900, 
San Diego, CA 92117, phone (619) 277-3888. 

Navy Micro/OA 88 Conference, July 25-28, 
San Diego, Calif. Contact Code 31.4, 
NARDAC San Diego, NAS North Island, 
Bldg. 1482, San Diego, CA 92135-5110, 
phone (619) 437-7013. 

International Computers in Engineering 
Conference and Exhibition (ASME), July 
31-Aug. 3, San Francisco. Contact ASME 
Meetings Dept., 345 E. 47th St., New York, 
NY 10017, phone (212) 705-7788. 


August 1988 


72^. SIGGraph 88, 15th Conference and 
*5*7 Exhibition on Computer Graphics and 
Interactive Techniques (ACM), Aug. 1-5, 
Atlanta. Contact Adele Newton, University 
of Waterloo, Dept, of Computer Science, 
Waterloo, Ontario, Canada N2L 3G1, phone 
(519)888-4534. 


1988 International Computers in Engineering 
Conference (ASME), Aug. 7-11, San Fran¬ 
cisco. Contact Edward M. Patton, US Army 
Ballistic Research Lab, Aberdeen Proving 
Grounds, MD 21005. 


Structured Development Forum X (Lawrence 
Livermore National Laboratory), Aug. 8-11, 

San Francisco. Contact Ted Michels, LLNL, 
PO Box 808, L-308, Livermore, CA 94550, 
phone (415) 423-4660. 

Third International Conference on Applica¬ 
tions of Artificial Intelligence in Engineer¬ 
ing, Aug. 8-12, Stanford, Calif. Contact R. 
Adey, Computational Mechanics Institute, 

25 Bridge St., Billerica, MA01821, phone 
(617) 667-7582. 

Seventh Conference of the Molecular 
Graphics Society, Aug. 10-12, San Fran¬ 
cisco. Contact Molecular Graphics Confer¬ 
ence Office, 16951 Pacific Coast Hwy., PO 
Box 385, Sunset Beach, CA 90742, phone 
(213) 592-1382. 

31st Midwest Symposium on Circuits and 
Systems, Aug. 11-12, Sf. Louis, Mo. Contact 
R. Eugene Stuffle, Dept, of Electrical 
Engineering, 317 Engineering Research 
Laboratory, University of Missouri, Rolla, 
MO 65401-0249, phone (314) 341-4371. 

Joint Fifth Symposium and Fifth Inter- 
*587 national Conference on Logic Pro¬ 
gramming (Assoc, for Logic Programming), 
Aug. 15-19, Seattle. Contact Kenneth A. 
Bowen, LP88, Logic Programming Research 
Group, School of Computer and Informa¬ 
tion Science, 313 Link Hall, Syracuse Uni¬ 
versity, Syracuse, NY 13210, phone (315) 
423-2466/67. 

ICPP 17, 17th International Conference on 
Parallel Processing, Aug. 15-19, St. Charles, 
Ill. Contact David H. Bailey, MS 258-5, 
NASA Ames Research Center, Moffett 
Field, CA 94035; Howard E. Sturgis, Xerox 
Corp., Palo Alto Research Center, 3333 
Coyote Hill Rd., Palo Alto, CA 94304; or 
Faye A. Briggs, Sun Microsystems, 2550 
Garcia Ave., Mountain View, CA 94043. 

DIAC 88, Directions and Implications of 
Advanced Computing Symposium (CPSR), 
Aug. 21, St. Paul, Minn. Contact Doug 
Schuler, Computer Professionals for Social 
Responsibility, PO Box 717, Palo Alto, CA 
94301, phone (206) 865-3226. 


AAAI 88, Seventh National Conference on 
Artificial Intelligence (AAAI), Aug. 21-26, 

St. Paul, Minn. Contact American Assoc, 
for Artificial Intelligence, 445 Burgess Dr., 
Menlo Park, CA 94025, phone (415) 
328-3123. 


CAD/CAM Technology Transfer to Latin 
America Conference (IFIP), Aug. 22-26, 

Mexico City. Contact G. Leon Lastra, Insti¬ 
tute de Investigaciones Electricas, Apdo. 
Postal 5-849, 11590 Mexico, D.F., phone 
(52) 73-129-632. 

Coling 88, 12th International Conference on 
Computational Linguistics, Aug. 22-27, 

Budapest, Hungary. Contact Coling 88 
Secretariat, Mtesz Congress Bureau, H-1055 
Budapest, Kossuth ter. 6-8, Hungary. 


LFA 88, Sixth IEEE Workshop on 
5*7 Languages for Automation, Aug. 
29-31, College Park, Md. Contact Panos A. 
Ligomenides, Electrical Engineering Dept., 
University of Maryland, College Park, MD 
20742, phone (301) 454-6842. 


International Forum on Increasing Manage¬ 
ment Productivity with Intelligent Systems, 
Aug. 29-31, Snowmass-Aspen, Colo. Con¬ 
tact Center for Applied Artificial Intelli¬ 
gence, College of Business and 
Administration, University of Colorado, 
Campus Box 419, Boulder, CO 80309, phone 
(303) 492-8229. 


14th International Conference on Very 
*5^* Large Databases (VLDB Endowment), 
Aug. 29-Sept. 1, Los Angeles. Contact Jack 
E. Shemer, Teradata Corp., 12945 Jefferson 
Blvd., Los Angeles, CA 90066, phone (213) 
827-8777. 


EuroMicro 88, 14th Symposium on 
Microprocessing and Microprogramming, 
Aug. 29-Sept. 1, Zurich. Contact EuroMicro 
88, PO Box 545, 7500 AM Enschede, The 
Netherlands, phone (31) 53-338-799. 


International Conference on Computer Pro¬ 
cessing of Chinese and Oriental Languages, 
Aug. 29-Sept. 1, Toronto, Canada. Contact 
C.N. Liu, IBM T.J. Watson Research Cen¬ 
ter, PO Box 704, Yorktown Heights, NY 
10598, phone (914) 789-7531. 


ICO Topical Meeting on Optical Com- 
*5*7 puting, Aug. 30-Sept. 2, Orsay, 

France. Contact S. Lowenthal, Insitut D’Up- 
tique, BP 43, 91406 Orsay Cedex, France. 


Z2N ITC 88, 1988 International Test Con- 
*5*7 ference, Aug. 30-Sept. 2, Washington, 
DC. Contact ITC 88, Computer Society, 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-1013. 


September 1988 


Crypto 88 (IACR), Aug. 21-25, Santa 
*5*7 Barbara, Calif. Contact Harold 
Fredricksen, Mathematics Dept., Code 53Fs, 
Naval Postgraduate School, Monterey, CA 
93943, phone (408) 646-2206. 


International Neural Network Society 
*5*7 Conference, Sept. 6-10, Boston. Con¬ 
tact INNS Conference, J.R. Schuman 
Associates, PO Box 125, 316 Washington 
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St., Wellesley, MA 02181, phone (617) 
237-7931. 


1988 International Test Conference, 
^5? Sept. 12-14, Washington, DC. Contact 
Doris Thomas, ITC, PO Box 264, Mt. Free¬ 
dom, NJ 07970, phone (201) 895-5260. 


NCGA Mapping and Geographic Informa¬ 
tion Systems 88, Sept. 12-15, Orlando, Fla. 
Contact NCGA, National Computer 
Graphics Assoc., 2722 Merrilee Dr., Suite 
200, Fairfax, VA 22031. 


Eurographics 88, Ninth European Assoc, for 
Computer Graphics Conference (INRIA), 
Sept. 12-16, Nice, France. Contact INRIA, 
Service des Relations Exterieures, Domaine 
de Voluceau, BP 105, 78153 Le Chesnay 
Cedex, France, phone (33) 1-39-635-501. 

Fourth International Conference of 
^*7 Modeling Techniques and Tools for 
Computer Performance Evaluation, Sept. 
15-17, Palma de Mallorca, Spain. Contact 
Ramon Puigjaner, UIB, Miguel dels Sants 
Oliver 2, 07012 Palma de Mallorca, Spain, 
phone (34) 71-725-706. 


IEEE Artificial Neural Networks Con- 
^57 ference. Sept. 18-21, Reston, Va. Con¬ 
tact Kamal Karma, 823 Flegler Rd., 
Gaithersburg, MD 20879, phone (301) 
984-7657. 


Fourth International Symposium on Biologi¬ 
cal and Artificial Intelligence Systems, Sept. 

18- 22, Trento, Italy. Contact Alberta Mar¬ 
tino, IBM Corp., Dept. 48B/428, Neighbor¬ 
hood Rd., Kingston, NY 12401, phone (914) 
385-4964. 

Sixth Software Quality Conference (Pacific 
Northwest Software Quality Conference 
Committee), Sept. 19-20, Portland, Ore. 
Contact Mary Lawrence, Lawrence & Craig, 
320 SW Stark, Rm. 411, Portland, OR 
97204, phone (503) 222-2606. 

Conference on Computerized Assistance 
During System Life Cycle (IFIP), Sept. 

19- 22, London. Contact International Feder¬ 
ation for Information Processing, 3 rue de 
Marche, CH-1204, Geneva, Switzerland. 

Workshop and Symposium on Formal Tech¬ 
niques in Real-time and Fault-tolerant Sys¬ 
tems, Sept. 20-23, Coventry, England. 
Contact M. Joseph, Dept, of Computer 
Science, University of Warwick, Coventry, 
CV4 7AL, UK. 


al Workshop oi 


v*7 Transaction Machine Architecture, 
Sept. 25-28, Lake Arrowhead, Calif. Con¬ 
tact Martin Freeman, Signetics Corp., 811 E. 
Arques Ave., Sunnyvale, CA 94086, phone 
(408) 991-3591. 

OOPSLA 88 (ACM), Sept. 25-29, San 
Diego, Calif. Contact Barbara Noparstak, 
Digitalk, Inc., 9841 Airport Blvd, Los 
Angeles, CA 90045, phone (213) 645-1082. 


Giorgio Valle, Universita di Milano, Dip. di 
Sciencze dell’Informazione, Via Moretto 9, 
20133 Milano, Italy, phone (39) 02-2772-228. 


/£3^j Second International Workshop on 
Object-Oriented Programming Data¬ 
base Systems (ACM), Sept. 27-30, Bad 
Muensteram Stein-Ebernburg, Germany. 
Contact Alex Buchmann, CCA, Four Cam¬ 
bridge Center, Cambridge, MA 02142, 
phone (617) 492-8860. 


26th Allerton Conference on Communica¬ 
tion, Control, and Computing, Sept. 28-30, 

Monticello, Ill. Contact Allerton Confer¬ 
ence, c/o Mark W. Spong, Coordinated 
Science Laboratory, University of Illinois at 
Urbana-Champaign, 1101 W. Springfield 
Ave., Urbana, IL 61801, phone (217) 
333-4281. 


October 1988 


ICCD 88, IEEE International Confer- 
vS7 ence on Computer Design, Oct. 2-6, 

Rye Brook, N.Y. Contact ICCD 88, Com¬ 
puter Society, 1730 Massachusetts Ave. NW, 
Washington, DC 20036-1903, phone (202) 
371-1013. 

EWSL 88, Third European Working Session 
on Learning, Oct. 3-5, Glasgow, Scotland. 
Contact Derek Sleeman, Dept, of Comput¬ 
ing Science, University of Aberdeen, Aber¬ 
deen AB9 2UB, Scotland, UK, phone (44) 
224-272-288. 

£3^! Compsac 88, 12th International Com¬ 
ply puter Software and Applications Con¬ 
ference, Oct. 3-7, Chicago. Contact Wing N. 
Toy, Compsac 88, AT&T Bell Laboratories, 
Rm. 1Z-306, 200 Park Plaza, Naperville, IL 
60566, phone (312) 416-4046; or Computer 
Society, 1730 Massachusetts Ave. NW, 
Washington, DC 20036-1903, phone (202) 
371-1013. 

1988 International Display Research Confer¬ 
ence (IEEE, SID), Oct. 4-6, San Diego, 

Calif. Contact Palisades Institute for 
Research Services, Attn. IDRC, 201 Varick 
St., New York, NY 10014, phone (212) 
620-3388. 

International Workshop on Defect and 
Fault Tolerance in VLSI Systems, Oct. 
6-7, Springfield, Mass. Contact Israel Koren, 
Dept, of Electrical and Computer Engineer¬ 
ing, University of Massachusetts, Amherst, 
MA 01003, phone (413) 545-2643. 

NCGA CAD/CAM 88, Oct. 9-12, Boston. 
Contact NCGA CAD/CAM 88, National 
Computer Graphics Assoc., 2722 Merrilee 
Dr., Suite 200, Fairfax, VA 22031. 

ICCL 88, International Conference on 
\57 Computer Languages, Oct. 9-13, 

Miami Beach, Fla. Contact Pei Hsia, Com¬ 
puter Science, University of Texas, 2100 Oak 
Bluff Dr., Arlington, TX 76001, phone (817) 
273-3785. 


f£3^j Seventh Symposium on Reliable Dis- 
\57 tributed Systems, Oct. 10-12, 

Columbus, Ohio. Contact David Cohen, 
Tekuekron Infoswitch, 1784 Firman Dr., 
Richardson, TX 75081; or Ming T. Liu, 
Dept, of Computer and Information 
Science, Ohio State University, 2036 Neil 
Ave., Columbus, OH 43210-1277, phone 
(614)292-1837. 

® 1988 IEEE Workshop on Visual Lan¬ 
guages, Oct. 10-12, Pittsburgh. Con¬ 
tact Erland Jungert, Dept, of Computer 
Science, University of Pennsylvania, Pitts¬ 
burgh, PA 15260; Alfs T. Berztiss, Com¬ 
puter Science Dept., Faculty of Arts and 
Sciences, University of Pittsburgh, 322 
Alumni Hall, Pittsburgh, PA 15260; or 
Stefano Levialdi, Departimento di Matemat- 
ica, Universita di Roma, Piazzale A. Moro, 
00185, Rome, Italy. 

13th Conference on Local Computer 
^57 Networks, Oct. 10-12, Minneapolis, 
Minn. Contact Ron Rutledge, MS-271, Mar¬ 
tin Marietta Energy Systems, Oak Ridge 
National Laboratory, Oak Ridge, TN 37831, 
phone (615) 576-7643. 

Frontiers 88, Second Symposium on 
the Frontiers of Massively Parallel 
Computation, Oct. 10-12, Fairfax, Va. Con¬ 
tact James R. Fischer, Frontiers 88 Sympo¬ 
sium, Code 635, NASA Goddard Space 
Flight Center, Greenbelt, MD 20771, phone, 
(301) 286-3464. 


International Workshop on Computer 
Vision (IAPR), Oct. 12-14, Tokyo. Contact 
Mikio Takagi, Institute of Industrial 
Science, University of Tokyo, 7-22-1, Rop- 
pongi, Minato-ku, Tokyo 106, Japan, phone 
(81) 3-479-0289. 

ACM SIGGraph Symposium on User Inter¬ 
face Software, Oct. 17-19, Banff, Canada. 
Contact John Sibert, Dept, of Electrical 
Engineering and Computer Science, George 
Washington University, Washington, DC 
20052, phone (202) 994-4953. 

Fourth International Conference on Satellite 
Systems for Mobile Communications and 
Navigation (IEE), Oct. 17-19, London. Con¬ 
tact Conference Services Dept., Institution 
of Electrical Engineers, Savoy PL, London 
WC2R 0BL, UK, phone (44) 01-240-1871. 


Ninth International Conference on Pattern 
Recognition (IAPR), Oct. 17-20. Contact 
M. J.B. Duff, Dept, of Physics and 
Astronomy, University College London, 
Gower St., London WC1E 6BT, England, 
UK, phone (01) 380-7010; or H. Freeman, 
CAIP Center, Rutgers University, Piscata- 
way, NJ 08855-1390, phone (201) 932-3443. 

ESIG 88, Fourth Expert Systems in 

Government Conference, Oct. 17-21, 

Washington, DC. Contact ESIG 88, MS 
W418, Mitre Corp., 7525 Colshire Dr., 
McLean, VA 22102; or Computer Society, 
1730 Massachusetts Ave. NW, 20036-1903, 
phone (202) 371-1013. 
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Neural Network 
Development Tools 

on the IBM PC, XT, AT and SUN workstations 
for 

rapid prototyping and concept testing 
of neural network designs 



Stock Market Forecasting 


from 

NeuralWare™ 


Pop-up menus make 
NeuralWorks Professional II 
easy to learn, easy to use 


NeuralWorks 
Professional II 

Includes 13 network types plus 
the ability to define your own 
network, 14 learning rules, 10 
transfer functions, 11 summa¬ 
tion functions. 

IBM PC $995; SUN $2,995. 

NeuralWorks Explorer 

Lets you get your feet wet in 
neural computing without in¬ 
vesting a lot of money. 

IBM PC $199; SUN $795. 


Full color screens and 
effective graphics 

guide you through the network¬ 
building and testing process 

Documentation includes 
extensive introduction to get 
you up to speed in neural 
computing 

Solve modeling and 
forecasting problems 

• finance and economics 

• servo control 

• sensor processing 

• CAD/CAM modeling 


Seminars 

Five-day, hands-on, applica¬ 
tions oriented. Available 
throughout the country. Also 
available for customized in- 
house presentation. 

Custom engineering 

Let us help solve your special 
problem. 


Call TODAY or write for informa¬ 
tion about NeuralWare’s software, 
seminars, and custom engineering 
services. Ask for Jane 
Klimasauskas, Vice-President 
Sales & Marketing. 


Solve signal 
processing problems 

• noise filtering 

• matched filters & speech 
recog 

• data compression 

Solve expert systems 
problems 

• adaptive expert systems 

NeuralWare, Inc. 

103 Buckskin Court 
Sewickley, PA 15143 U.S.A. 
412-741-5959 



Expert Systems 


NOISE FILTERING EXAMPLE 
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Noise Filtering 



Modeling 
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NeuralWare™ is applied neural computing. 
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CALL FOR PAPERS 


Call for papers and referees for Computer 


Computer seeks articles for inclusion in 
several upcoming special issues. 


Robotics and Automation is the theme 
slated for the March 1989 issue. 

Suggested topics include 

• how the goals of robotics have and 
will influence computer science 
research; 

• applications of theoretical computer 
science in robotics; 

• design and complexity analysis of 
algorithms for motion planning in 
known or unknown environments; 

• issues in computational geometry; 

• strategies for stable grasping of 

• representation of complex objects 
for modeling, and reasoning about 
such objects (for example, determin¬ 
ing manufacturability of an object 
calculating center of mass, simulat¬ 
ing physical systems) 

• computer language design issues for 
robotics such as concurrency, data 
abstraction, and real-time issues; 

• efficient use of sensor information 
(vision, odometry, range finders). 

Papers must not have been previously 
published or currently submitted for pub¬ 
lication elsewhere. 

A 300-word abstract of the manuscript 
should be submitted as soon as possible. 
Eight copies of the full manuscript 
should be submitted by July 1, 1988 to 
Gordon T. Wilfong, AT&T Bell Labora¬ 
tories, Murray Hill, NJ 07974, phone 
(201) 582-3561, E-mail address: 
gtw % research. att .com @relay. cs. net. 

Authors will be notified of acceptance by 
Oct. 15,1988. The final version of the 
manuscript is due no later than Nov. 15, 
1988. 

Persons interested in serving as referees 
are asked to send a note to Wilfong with 
a list of technical interests. 


• test-generation techniques; 

• fault-simulation techniques; 

• interface between CAD systems and 
the factory; 

• tools for diagnosis; 

• tools for design for testability and 
built-in self test; 

• expert systems and other artificial 
intelligence tools for test; and 

• other testing applications. 

Papers must not have been previously 
published or currently submitted for pub¬ 
lication elsewhere. 

A 300-word abstract should be submitted 
as soon as possible. Eight copies of the 
full manuscript should be submitted by 
July 1,1988 to Scott Davidson, AT&T 
Engineering Research Center, PO Box 
900, Princeton, NJ 08540, phone (609) 
639-2289, E-mail: ihnp4!erc3ba!sd. 

Authors will be notified of acceptance by 
Nov. 8,1988. The final version of the 
manuscript is due no later than Jan. 1, 
1989. 

Persons interested in serving as referees 
are asked to send a note to Davidson with 
a list of technical interests. 


Rapid Prototyping is the theme slated for 
the May 1989 issue. 

Suggested topics include 

• the role of knowledge engineering in 
prototyping environments; 

• rapid prototyping of real-time 
systems; 

• domain-specific rapid prototyping 
systems; 

• reusability in prototyping envi¬ 
ronments; 

• support tools for prototyping envi¬ 
ronments; 

• prototyping experience with ART, 
KEE, PC + , etc.; 

• prototyping experience with C + +, 
Smalltalk, Flavors Objective-C, 

Ada, etc.; and 

• prototyping experience with CASE 
tools. 


Software Tools for Hardware Test is the 

theme scheduled for the April 1989 issue. 

Suggested topics include 

• algorithms and data structures for 
computer-aided test tools; 


Papers must not have been previously 
published or currently submitted for pub¬ 
lication elsewhere. 

A 300-word abstract should be submitted 
as soon as possible. Eight copies of the 
full manuscript should be submitted by 


Sept. 1,1988 to Murat M. Tanik, Com¬ 
puter Science and Engineering Depart¬ 
ment, Southern Methodist University, 
Dallas, TX 75275, phone (214) 692-2854, 
E-mail: smu.tanik@uunet.uu.net; or to 
Raymond T. Yeh, ISSI International, 
9420 Research Blvd., Suite 2000, Austin, 
TX 78759, phone (512) 338-1895, csnet: 
issi @emx .utexas.edu. 

Authors will be notified of acceptance by 
Dec. 1,1988. The final version of the 
manuscript is due no later than Jan. 1, 
1989. 

Persons interested in serving as referees 
are asked to send a note to Tanik with a 
list of technical interests. 


Autonomous Intelligent Machines is the 

theme scheduled for the June 1989 issue. 

Suggested topics include 

• distributed and parallel architectures 
for intelligent machines; 

• multisensor integration for intelli¬ 
gent machine applications; 

• real-time control and coordination 
of mobile robots and manipulators; 

• machine intelligence and expert 
systems; 

• robot programming. 

• path planning and navigation; and 

• learning and autonomous machines. 

Papers must not have been previously 
published or currently submitted for pub¬ 
lication elsewhere. 

A 300-word abstract should be submitted 
as soon as possible. Eight copies of the 
full manuscript must be submitted by 
Oct. 1, 1988 to S. Sitharama Iyengar, 
Department of Computer Science, Loui¬ 
siana State University, Baton Rouge, LA 
70803-4020, phone (504) 388-1495, E- 
mail: iyengar%lsu.edu@relay.csnet; or 
to Rangasami L. Kashyap, Department 
of Electrical Engineering, Purdue Univer¬ 
sity, West Lafayette, IN 47907, phone 
(317) 494-3473, csnet E-mail address: 
kashyap@ee.ecn.purdue.edu. 

Authors will be notified of acceptance by 
Jan. 10, 1989. The final version of the 
manuscript is due no later than Feb. 25, 
1989. 

Persons interested in serving as referees 
are asked to send a note to Iyengar or 
Kashyap with a list of technical interests. 
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1988 International Computer Science 
Conference: Dec. 19-21, 1988, Hong 
Kong. Submit paper by June 15, 1988 to 
Jean-Louis Lassez, IBM T.J. Watson 
Research Center, PO Box 218, Yorktown 
Heights, NY 10598; or Francis Y.L. Chin, 
Center of Computer Studies and Applica¬ 
tion, University of Hong Kong, Hong Kong. 

Fifth International Conference on 
99 Data Engineering: Feb. 7-9, 1989, Los 
Angeles. Submit paper by June 15, 1988 to 
Richard L. Shuey, Computer Science Dept., 
Rensselaer Polytechnic Institute, Troy, NY 
12189-3590, phone (518) 276-8376 or (518) 
374-5684. 

IFIP TC-2 Working Conference on Visual 
Database Systems (IPSJ): Apr. 3-7, 1989, 
Tokyo. Submit paper by June 15, 1988 to 
IFIP TC-2 Working Conference, Tosiyasu 
L. Kunii, Dept, of Information Science, 
Faculty of Science, University of Tokyo, 

7-3-1 Hongo, Bunkyo-ku, Tokyo 113, 

Japan, phone (81) 03-812-2111, ext. 4116. 

AIDA 88, Fourth Conference on Artificial 
Intelligence and Ada: Nov. 15-16, 1988, 
Washington, DC. Submit paper by June 24, 
1988 to John Moore, Software Productivity 
Consortium, 1880 Campus Commons Dr. 
North, Reston, VA 22091, phone (703) 
391-1729. 

Proceedings of the IEEE: January 1990. A 
special issue on state-of-the-art surveys on 
supercomputing technology is planned. Sub¬ 
mit paper or proposal by June 30, 1988 to 
Tse-yun Feng or A.R. Hurson, E.E. East 
Bldg., Pennsylvania State University, Uni¬ 
versity Park, PA 16802, phone (814) 

863-1469 or 1187. 

IEEE Transactions on Computers (IEEE- 
TC): April 1989. Papers are sought for a spe¬ 
cial issue on high-yield VLSI systems. Sub¬ 
mit manuscript by July 1, 1988 to Israel 
Koren, Dept, of Electrical and Computer 
Engineering, 210 Marcus Hall, University of 
Massachusetts, Amherst, MA 01003, phone 
(413) 545-2643. 

Second International Workshop on Artificial 
Intelligence in Economics and Management 
(IFIP, IFAC, IFORS): Jan. 11-13, 1989, Sin¬ 
gapore. Submit extended abstract by July 1, 
1988 to Vicky Toh, Institute of Systems 
Science, National University of Singapore, 
Kent Ridge, Singapore 0511. 

Micro 21, Workshop on Micropro- 
99 gramming and Microarchitecture 

(ACM): Nov. 28-Dec. 1, 1988, San Diego, 
Calif. Submit paper by July 1, 1988 to Wen- 
Mei Hwu, Coordinated Science Laboratory, 
University of Illinois at Urbana-Champaign, 
1101 W. Springfield Ave., Urbana, IL 
61801, phone (217) 244-8270. 

IEEE Workshop on Visual Motion: 

*51? Mar. 20-22, 1989, Irvine, Calif. Submit 
paper by July 15, 1988 to Ellen Hildreth, 
Artificial Intelligence Laboratory, 545 Tech¬ 
nology Square, Cambridge, MA 02139; or 
Ramesh Jain, Electrical Engineering and 


Computer Science Dept., University of 
Michigan, Ann Arbor, MI 48109-2122. 

£2^. PCCC 89, Phoenix Conference on 
*99 Computers and Communications: 

Mar. 22-24, 1989, Scottsdale, Ariz. Submit 
paper by July 15, 1988 to one of the follow¬ 
ing: Frank Boesch, Chairman, EECS, 

Stevens Institute of Technology, Hoboken, 

NJ 07030 (for US East Coast authors); 

Dennis Allison, Computer Science Lab, 
ERL-444, Stanford University, Stanford, 

CA 94305 (for US West Coast); Giulio 
Occhini, Honeywell Bull, Via Vida 11, 

Milan, Italy (for Europe); Richard Duke, 
Faculty of Engineering, University of Can¬ 
terbury, Private Bag, Christchurch, New 
Zealand (Australia/New Zealand); or 
Makoto Nagao, Dept, of Electrical 
Engineering, Kyoto University, Kyoto, 

Japan (for Asia). 

26th Allerton Conference on Communica¬ 
tion, Control, and Computing: Sept. 28-30, 
1988, Monticello, Ill. Submit paper and 
extended abstract by July 15, 1988 to Aller¬ 
ton Conference, c/o Mark W. Spong, Coor¬ 
dinated Science Laboratory, University of 
Illinois at Urbana-Champaign, 1101 W. 
Springfield Ave., Urbana, IL 61801, phone 
(217)333-4281. 

ICS 88, 1988 International Computer Sym¬ 
posium: Dec. 20-21, 1988, Taipei, Taiwan. 
Submit paper by July 15,1988 to Louis R. 
Chow, Tamkang University, Tamsui, Tai¬ 
wan, Republic of China (for authors in the 
Far East); or to Shi-Kuo Chang, Dept, of 
Computer Science, University of Pittsburgh, 
Pittsburgh, PA 15260 (for authors outside 
the Far East). 

IEEE Software: March 1989. Articles 
*99 are sought for a special issue on soft¬ 
ware technology in the Far East. Submit 
manuscript by Aug. 1, 1988 to Carl Chang, 
Guest Editor, EECS Dept., MC 154, Univer¬ 
sity of Illinois, PO Box 4348, Chicago, IL 
60680, phone (312) 996-4860. 

® IEEE Infocom 89, Conference on 
Computer Communications: Apr. 
24-27, 1989, Ottawa, Canada. Submit paper 
by Aug. 1, 1988 to J.W. Mark, IEEE Info¬ 
com 89, Dept, of Electrical Engineering, 
University of Waterloo, Waterloo, Ontario, 
Canada N2L 3G1, phone (519) 888-4016. 

ASPLOS III, Third International Con- 
99 ference on Architectural Support for 
Programming Languages and Operating Sys¬ 
tems (ACM): Apr. 3-6, 1989, Boston. Sub¬ 
mit paper by Aug. 1, 1988 to John Hennessy, 
Center for Integrated Systems, Stanford 
University, Stanford, CA 94305. 

Z2N Second International Workshop of 
99 VLSI Design (Computer Society of 
India): Dec. 15-18, 1988, Bangalore, India. 
Submit paper by Aug. 1, 1988 to Ravi M. 
Apte, Valid Logic Systems, 2820 Orchard 
Pkwy, San Jose, CA 95134, phone (408) 
432-9400; or A. Prabhakar, Indian Tele¬ 
phone Industries, Dooravani Nagar, Ban¬ 
galore 560 016, India, phone (812) 563-211. 


ETC 89, First European Test Conference 
(SEE): Apr. 12-14, 1989, Paris. Submit 
paper by Aug. 1,1988 to ETC 89, 48 Rue de 
la Procession, 75724 Paris Cedex 15, France. 

ZSN CompEuro 89, International Confer- 
99 ence on VLSI and Computer 
Peripherals: May 8-12, 1989, Hamburg. Sub¬ 
mit paper by Aug. 15,1988 to Walter E. 
Proebster, IBM Laboratory, PO Box 1380, 
D-7030 Boeblinger, Federal Republic of 
Germany. 

IEEE Globecom 88: Dec. 1-2, 1988, Holly¬ 
wood, Fla. Submit paper by Aug. 15, 1988 to 
Dennis J. Sassa, Bell Communications 
Research, NVC 2Z-129, 331 Newman 
Springs Rd., Red Bank, NJ 07701-7020, 
phone (201) 446-6787. 

34th International Instrumentation Sympo¬ 
sium (ISA): Apr. 30-May 4, 1989, Orlando, 
Fla. Submit paper by Aug. 15, 1988 to 
Frederick A. Kern, PO Box 65, Seaford, VA 
23696, phone (804) 865-3269. 

First International Symposium on Artificial 
Intelligence: Oct. 24-28, 1988, Monterrey 
N.L., Mexico. Submit paper by Aug. 31, 
1988 to Francisco J. Cantu, Instituto Tec- 
nologico de Monterrey, ITESM Sue. Correos 
“J”, Monterrey N.L., Mexico, 64849, phone 
52 (83) 595-943. 

IEEE Software will publish a special 
99 edition on parallel-processing lan¬ 
guages in July 1989. Submit paper by Sept. 

1, 1988 to Shreekant Thakkar, Sequent 
Computer Systems, 15450 SW Koll Pkwy, 
Beaverton, OR 97006. 


ZZN IEEE Software will publish a special 
99 issue on verification and validation in 
May 1989. Submit article by Sept. 1, 1988 to 
Dolores Wallace, National Bureau of Stan¬ 
dards, B-266 Technology Bldg., Gaithers¬ 
burg, MD 20899, phone (301) 975-3340; or 
Robert Fujii, Logicon, 355 W. Fifth St., San 
Pedro, CA 90733, phone (213) 831-0611. 

17th Computer Science Conference (ACM): 

Feb. 21-23, 1989, Louisville, Ky. Submit 
paper by Sept. 1, 1988 to John D. 

McGregor, Dept, of Computer Studies, 
Murray State University, Murray, KY 42071. 

Z2N 11th International Conference on Soft- 
99 ware Engineering (ACM): May 15-18, 
1989, Pittsburgh. Submit paper by Sept. 15, 
1988 to Richard Fairley, School of Informa¬ 
tion Technology, George Mason University, 
Fairfax, VA 22030; or Dines Bjorner, Dansk 
Datamatik Center, Lundtoftevej 1 C, 

Lyngby DK-280O, Denmark. 

CHI 89, Conference on Human Fac- 
99 tors in Computing Systems (ACM, 
HFS): Apr. 30-May 4, 1989, Austin, Texas. 
Submit paper by Sept. 26, 1988 to Clayton 
Lewis, Dept, of Computer Science, Campus 
Box 430, University of Colorado, Boulder, 
CO 80309, phone (303) 492-6657. 
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CAREER OPPORTUNITIES 


RATES: $12.00 per line, $120 
minimum charge (up to ten lines). 
Average six typeset words per line, eight 
lines per column inch. Add $10 for box 
number. Send copy at least one month 
prior to publication to: Heidi Rex or 
Marian Tibayan, Classified Advertis¬ 
ing, COMPUTER Magazine, 10662 
Los Vaqueros Circle, Los Alamitos, CA 
90720; (714) 821-8380. 

In order to conform to the Age Discrimi¬ 
nation in Employment Act and to dis¬ 
courage age discrimination, COMPUTER 
may reject any advertisement containing 


COMPUTER SYSTEMS 
INFORMATION ANALYST 

Minimum 3 years experience with BS 
degree either computer, electrical or elec¬ 
tronics with some computer and data process¬ 
ing experience. Will assist this public health 
care firm in providing an efficient information 
and review system in connection with our 
public care programs. Will also synchronize 
and tap the maximum output from the exist¬ 
ing computer systems in addition to develop¬ 
ing newer systems for meeting the require¬ 
ments of data processing and information 
analysis. Salary $34,800 yr. Send resume: 
PractiCare Inc., 2707 So. Central Ave., Los 
Angeles, CA 90011. 


UNIVERSITY OF CALIFORNIA, 
SAN DIEGO 

The Department of Applied Mechanics and 
Engineering Sciences is seeking a promising 
individual to fill a position at the assistant Pro¬ 
fessor level (tenure track) in the Applied 
Mechanics and Engineering Sciences Depart¬ 
ment (AMES). UCSD intends to establish an 
academic and research program in Robotics 
and Automation. The individual sought will be 
expected to assist in developing this new pro¬ 
gram and work in concert with other faculty 
members. Research focus in intelligent control 
of complex systems is especially attractive. Ex¬ 
amples of appropriate specialties would in- 


any of these phrases or similar ones: 
“...recent college grads...,” “...1-4 years 
maximum experience...,” “...up to 5 years 
experience....” or “...10 years maximum 
experience.” COMPUTER reserves the 
right to append to any advertisement, 
without specific notice to the advertiser, 
“Experience ranges are suggested mini¬ 
mum requirements, not maximums.” 
COMPUTER assumes that, since adver¬ 
tisers have been notified of this policy in 
advance, they agree that any experience 
requirements, whether stated as ranges or 
otherwise, will be construed by the reader 
as minimum requirements only. 


elude design of image based systems, control 
of discrete event processes, neurocomputing, 
implications of systems architecture and vari¬ 
ous communication protocols on the design of 
decentralized systems. Examples of campus- 
related activities that suggest the need for a 
focused program include work in prosthetics 
at associate medical facilities, space-related 
work at the Cal Space Institute and undersea 
autonomous vehicle applications at the 
Scripps Institution of Oceanography. Duties 
associated with the position include develop¬ 
ing and conducting a program of scholarly 
research, supervising student programs of 
study and research at the graduate level, 
teaching at the undergraduate and graduate 
levels, assisting in the establishment of ap¬ 
propriate laboratories to support the teaching 
and research programs, and participating in 
the administrative functions of the University. 
Qualifications include an earned Ph.D. in an 
appropriate discipline and evidence of re¬ 
search potential. Applicants at all professional 
levels may be considered. Salary commen¬ 
surate with qualifications based upon UC pay 
scales. Applicants should respond with a suffi¬ 
ciently detailed resume (immigration status of 
non-citizens should be stated in resume) to 
support the position requisites and the names 
of at least five references to: Professor A.V. 
Sebald, Chairman, Robotics Search Commit¬ 
tee; Position A6; Department of Applied 
Mechanics and Engineering Sciences, B-010; 
University of California, San Diego; La Jolla, 
California 92093. Applications received by 
July 1, 1988 will receive full consideration. 
University of California is an Equal Oppor¬ 
tunity/Affirmative Action Employer. 


UNIVERSITY OF CALIFORNIA, 
SAN DIEGO 

The Department of Applied Mechanics 
and Engineering Sciences is seeking a distin¬ 
guished individual to fill a position at the full 
Professor level (tenure) in the Applied 
Mechanics and Engineering Sciences Depart¬ 
ment (AMES). UCSD intends to establish an 
academic and research program in Robotics 
and Automation. The individual sought will be 
expected to provide a leadership role in 
developing this new program and work in 
concert with other faculty members. Research 
focus in intelligent control of complex systems 
is especially attractive. Examples of appropri¬ 
ate specialties would inlcude design of image 
based systems, control of discrete event pro¬ 
cesses, neurocomputing, implications of sys¬ 
tems architecture and various communication 
protocols on the design of decentralized 
systems. Example of campus-related activities 
that suggest the need for a focused program 
include work in prosthetics at associate medi¬ 
cal facilities, space-related work at the Cal 
Space Institute and undersea autonomous 
vehicle applications at the Scripps Institution 
of Oceanography. Duties associated with the 
position include developing and conducting a 
program of scholarly research, supervising 
student programs of study and research at the 
graduate level, teaching at the undergraduate 
and graduate levels, establishing appropriate 
laboratories to support the teaching and 
research programs, and participating in the 
administrative functions of the University. 
Qualifications include an earned Ph.D. in an 
appropriate discipline, internationally 
recognized credentials in Robotics, well- 
established leadership abilities, demonstrated 
experience in the procurement and manage¬ 
ment of extramurally funded research proj¬ 
ects, and teaching experience. Applicants at 
all professional levels may be considered. 
Salary and rank commensurate with qualifica¬ 
tions based upon UC pay scales. Applicants 
should respond with a sufficiently detailed 
resume (immigration status of non-citizens 
should be stated in the resume) to support the 
position requisites and the names of at least 
five references to: Professor A.V. Sebald, 
Chairman, Robotics Search Committee; posi¬ 
tion F6, Department of Applied Mechanics 
and Engineering Sciences, B-010; University 
of California, San Diego; La Jolla, CA 92093. 
Applications received by July 1, 1988 will 
receive full consideration. University of 
California is an Equal Opportunity/Affir¬ 
mative Action Employer. 
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NAVAL POSTGRADUATE SCHOOL 
Position Announcement in 
Computer Science 

The Department of Computer Science has 
immediate openings for faculty positions at all 
levels. Our primary interests are in the areas of 
operating systems, distributed systems, pro¬ 
gramming languages, and algorithms. Our 
secondary interests are in the areas of process¬ 
ing of visual data, real-time systems, and soft¬ 
ware engineering. An applicant should have a 
PhD in Computer Science or a related field 
and have a strong interest in both graduate 
teaching and research. Senior applicants must 
have distinguished research records. Appoint¬ 
ments can begin at any time during the year. 

The Department offers MS and PhD 
degrees in Computer Science. Departmental 
facilities (supported by 9 full-time computer 
professionals) consist of six instructional and 
research laboratories including the Database 
Systems Laboratory, the Graphics and Video 
Laboratory, the Software Engineering Labo¬ 
ratory, the Microcomputer Systems Labora¬ 
tory, the Artificial Intelligence Laboratory and 
the Computer Science Academic Laboratory. 
In these laboratories are the latest, state-of- 
the-art computing equipment including LISP 
machines, high-performance graphics work¬ 
stations, bit-mapped graphics workstations, 
multi-microprocessor systems, etc. During the 
academic year, the faculty normally teach for 
two quarters and conduct full-time research 
supported by major research programs in both 
the Department of Defense and the non-DOD 
organizations during the other two quarters. 
New faculty receive initial support from an on- 
campus research foundation. 

Located on Monterey Bay, the areas of 
Monterey, Pebble Beach, and Carmel pro¬ 
vide a pleasant Northern California coastal 
climate and easy access to Silicon Valley com¬ 
panies and universities. 

Please send a detailed resume and three 
letters of reference to: 

Search Committee 

Computer Science Department (Code 52) 
Naval Postgraduate School 
Monterey, CA 93943 
Tel. No. (408) 646-2449 

AN EQUAL OPPORTUNITY/AFFIRMA¬ 
TIVE ACTION EMPLOYER. 


NAVAL POSTGRADUATE SCHOOL 
Computer Science Chairperson 

The Naval Postgraduate School invites ap¬ 
plications and nominations for the position of 
Chairperson of the Computer Science 
Department. We are seeking an individual 
who can provide leadership in both teaching 
and research to a strong and growing pro¬ 
gram. This person must have a Ph.D. in 
Computer Science or a closely related area 
and a distinguished record of research and 
publication as well as demonstrated adminis¬ 
trative capability. 

The Department offers M.S. and Ph.D. 
degrees in Computer Science. Currently, 110 
students are enrolled in the M.S. program and 
five in the Ph.D. program. No undergraduate 


degrees are offered. Students are military of¬ 
ficers or civilian employees of the Department 
of Defense and are fully supported by their 
sponsoring organization during their graduate 

The faculty currently consists of thirteen full¬ 
time civilian faculty, five military faculty, and 
several adjunct faculty. Additional positions 
are open in all areas. Departmental facilities 
(supported by eight full-time computer profes¬ 
sionals) consist of six instructional and re¬ 
search laboratories including the Database 
Systems Laboratory, the Graphics and Video 
Laboratory, the Software Engineering Labo¬ 
ratory, the Microcomputer Systems Labora¬ 
tory, the Artificial Intelligence Laboratory, and 
the Computer Science Academic Laboratory. 
In these laboratories are state-of-the-art com¬ 
puting equipment including a VAX 780, a 
VAX 785, LISP machines, high-performance 
graphics workstations, bit-mapped graphics 
workstations, and multi-microprocessor 
systems. 

Located on Monterey Bay, the areas of 
Monterey, Pebble Beach, and Carmel pro¬ 
vide a pleasant Northern California coastal 
climate and easy access to Silicon Valley com¬ 
panies and universities. 

Please send a detailed resume and letters of 
reference to: 

Chair Search Committee 
Computer Science Department (Code 52) 
Naval Postgraduate School 
Monterey, CA 93943 
Tel. No. (408) 646-2449 

AN EQUAL OPPORTUNITY/AFFIRMA¬ 
TIVE ACTION EMPLOYER. 


THE UNIVERSITY OF CALGARY 

Department of Computer Science 

The University of Calgary invites applica¬ 
tions for two faculty positions in the Depart¬ 
ment of Computer Science. The department 
has a strong research program as well as a 
commitment to teaching excellence at BSc, 
MSc and Ph.D. levels. Research is well sup¬ 
ported by external grants, funded chairs, and 
excellent physical facilities. 

Applicants are expected to have a Ph.D. in 
Computer Science, as well as some teaching 
experience. Preference will be given to can¬ 
didates with particular strength and interest in 
theoretical computer science. Duties will in¬ 
clude both research and teaching at the 
undergraduate and graduate level. Salary and 
rank are negotiable, but will likely be at the 
Assistant Professor level (current minimum: 
$31,247). Starting date: September 1, 1988 
or as soon as possible thereafter. 

In accordance with Canadian immigration 
requirements, priority will be given to Cana¬ 
dian citizens and permanent residents of 
Canada. 

Application, including a curriculum vitae 
and the names of three referees should be sent 
prior to July 15, 1988 to: 

Dr, John Kendall. Head 
Department of Computer Science 
The University of Calgary 
2500 University Drive. N.W. 

Calgary. Alberta Canada, T2N 1N4 
Telephone: (403) 220-5454 


CURTIN UNIVERSITY 
OF TECHNOLOGY 
Perth, Western Australia 

Applications are invited for appointment as 
Associate Professor in Information Systems in 
the School of Computing and Quantitative 
Studies. The School undertakes teaching and 
research associated with the analysis, design 
and implementation of information systems in 
organizations and the management of that 
process. The programmes offered are Bache¬ 
lor of Business (Information Processing); 
Bachelor of Business (Information Systems); 
Graduate Diploma in Business Computing; 
Postgraduate Diploma/Master of Business 
(Business Systems); Postgraduate Diploma/ 
Master of Information Systems; Ph.D. in In¬ 
formation Systems. 

The School has a growing international 
reputation in a number of aspects of Informa¬ 
tion Systems (namely Information Systems 
Planning and Strategy Formulation; System 
Development Methodologies; Decision Sup¬ 
port Systems; End-user Computing) and is 
looking to expand its activity in these and 
related fields (such as Software Engineering; 
Systems and Software Quality Assurance; 
System Design Approaches; Automated 
Support Tools; Executive Information Sys¬ 
tems; Commercial Exploitation of Expert 
Systems). 

The Associate Professor will take a leading 
role developing research and educational pro¬ 
grammes in some or all of these fields. In addi¬ 
tion to teaching the appointee will engage in 
research/scholarship; provide leadership/ 
guidance to both staff and postgraduate 
students; monitor the relevance of the 
School’s undergraduate/postgraduate offer¬ 
ings in the light of current trends. 

A record of scholarship, applied research 
and academic leadership is required together 
with relevant professional experience, pref¬ 
erably at a senior level. Candidates would 
normally be expected to hold a relevant 
higher degree. 

The School has as its principal equipment 
an Amdahl 470/V8 processor running the 
IBM MVS operating system with a range of 
system and application development software 
including the Cullinet IDMS/R database 
system. It has extensive micro computer 
facilities (with all academic staff in the School 
being supplied with a PC). It also has access to 
the University’s network of VAX computers 
using both VMS and UNIX and a very large 
range of Digital and third party software. 

The Salary is $50,103 (Aust) and the posi¬ 
tion is available with Tenure. However the 
University is interested in receiving applica¬ 
tions from persons able to undertake a visiting 
appointment. Applicants should state period 
of availability. 

Applications including names, addresses 
and telephone numbers of three referees 
should be submitted not later than 8 July 1988 
to the Appointments Officer, Curtin University 
of Technology, GPO Box U1987, Perth, 
Western Australia 6001. Further information 
may be obtained by Telex (AA 92983) or Fax 
(619) 458-4661 quoting “Appointments”, 
position reference number 1112 and your 
return airmail address. Telephone enquiries in 
business hours to Associate Professor R.D. 
Galliers (Australia) (619) 350-7027. Curtin is 
an equal opportunity employer. 
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UNIVERSITY OF ILLINOIS 
Assistant Specialist in 
Automated Education 
(CERL System Software Staff) 

The Computer-based Education Research 
Laboratory (CERL) of the University of Illinois 
has a full-time Assistant Specialist in Auto¬ 
mated Education position open on the CERL 
System Software Staff. 

DUTIES: architectural design of improve¬ 
ments and modifications to PLATO 
computer-based education systems; design, 
implementation and documentation of func¬ 
tional modules of PLATO systems; solving 
software and hardware problems encoun¬ 
tered in the operation of PLATO systems. 

QUALIFICATIONS: BS or BA and experi¬ 
ence in one or more of these areas: computer- 
based education (CBE), system design and 
development, mainframe and micro com¬ 
puters, assembly and high-level languages, 
and computer networking. The ability to work 
on one’s own initiative and to cooperate 
within a group of 10-20 people is essential. 
Familiarity with the PLATO TUTOR pro¬ 
gramming language, programming CDC 
Cyber computers using COMPASS, pro¬ 
gramming Motorola M68000 systems using 
assembler, Pascal and C, and SUN/UNIX 
knowledge are all desirable attributes. 

SALARY: Commensurate with achieve¬ 
ments and ability, minimum $25,000. The 
position is open now; the starting date is 
negotiable. 

CONTACT: Michael W. Walker, Head- 
System Software Staff, Computer-based 
Education Research Laboratory, University of 
Illinois, 252 Engineering Research Lab, 103 
S. Mathews, Urbana, Illinois 61801. 

Telephone: (217) 333-7316. 

To ensure full consideration, resume and 
salary requirements must be received by June 
24, 1988. 

The University of Illinois is an Affirmative 
Action/Equal Opportunity Employer. 


RESEARCH ASSOCIATE 

Research Associate for 2D Machine project 
and Nectar project; design and implement 
feature-level, intermediate-level and high- 
level computer vision algorithms on Warp; 
design parallel language to ensure efficient im¬ 
plementation; design system architecture of 
2D Machine to support research on computer 
vision; design computer vision to be imple¬ 
mented on Nectar: REQ: Ph.D. in Elec. & 
Comp. Eng. and state-of-the-art background 
in computer vision, parallel processing, com¬ 
puter network and computer engineering; 
must have proven research and publication 
accomplishments incl. 3D object recognition, 
3D structures from 2D images, multisensor 
fusion and parallel vision; background in 
design of computer vision system and im¬ 
plementing parallel vision algorithms on 
multiprocessors; knowl. of Warp, OPS and 
LISP; 40 hrs./wk.; $41,000/yr. Submit 
resume to PGH East Job Service, 6206 
Broad Street, Pittsburgh, PA 15206. Refer to 
J.O. #PA3849854. 


ARTIFICIAL INTELLIGENCE 
AND EXPERT SYSTEMS 


Tomorrow’s Computing 
Technology is Today’s Challenge 


-at- 

I DA 


Some of the nation’s most excit¬ 
ing developments in software 
technology, supercomputer 
architecture, AI, and expert sys¬ 
tems are under scrutiny right 
now at the Institute for Defense 
Analyses. IDA is a Federally 
Funded Research and Develop¬ 
ment Center serving the Office of 
the Secretary of Defense, the 
Joint Chiefs of Staff, Defense 
Agencies, and other Federal 
sponsors. 

IDA’s Computer and Software 
Engineering Division (CSED) is 
seeking professional staff 
members with an in-depth theo¬ 
retical and practical background 
in the area of Artificial Intelli¬ 
gence and Expert Systems tech¬ 
nology. Tasks include efforts on 
both the design and prototyping 
of expert system tools and appli¬ 
cations and providing advice to 
DoD decision makers on the 
appropriate use of and manage¬ 
ment policies regarding expert 
systems. 

Specific desired interests and 
skills include: 

• Analogic reasoning 

• Truth maintenance 

• Knowledge engineering 

• User interface (including 
natural language processing) 

• Hybrid (deterministic and 
heuristic) models and systems 

• List processing and logical 
programming language theory 


• Applications development with 
an emphasis on military plan¬ 
ning and information correla¬ 
tion/fusion 

Specialists in other areas of 
Computer Science are also 
sought: Distributed Systems, 
Programming Language 
Experts, Software Engineers, 
and Computer Security 
Specialists. 

We offer career opportunities at 
many levels of experience. You 
may be a highly experienced 
individual able to lead IDA proj¬ 
ects and programs ... or a 
recent MS/PhD graduate. You 
can expect a competitive salary, 
excellent benefits, and a superior 
professional environment. 

Equally important, you can 
expect a role on the leading edge 
of the state of the art in comput¬ 
ing. If this kind of future appeals 
to you, we urge you to investi¬ 
gate a career with IDA. Please 
forward your resume to: 

Mr. Thomas J. Shirhall 
Manager of Professional Staffing 
Institute for Defense Analyses 
1801 N. Beauregard Street 
Alexandria, VA 22311 
An equal opportunity employer. 
U.S. Citizenship is required. 
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BOOK REVIEWS 


Editor: Wiley McKinzie, School of Computer Science and Technology, Rochester Institute of Technology, Rochester, l\IY 14623; Compmail, w.mckinzie; CSnet, wrm@rit 


Unix System 
Programming 

Keith Haviland and Ben Salama 

(Addison-Wesley Publishing Co., 

Reading, Mass., 1987, 339 pp., 

$24.95) 

Before you skip to the next review 
because you are not a systems program¬ 
mer, reread the title. This is a book 
about writing programs for the Unix 
operating system, not rewriting Unix 
kernel code. 

The audience for this book is any 
programmer writing serious programs 
for a Unix system. The secondary 
audience is anyone who wants a better 
understanding of how Unix works. The 
book would also make an excellent text 
for students who have a working knowl¬ 
edge of Unix and the C language and 
want to further their understanding. 

After reviewing the fundamentals of 
Unix and introducing common terms, 
the book jumps right into using system 
calls for handling files, primarily in 
terms of access to data. Next, an explo¬ 
ration of the concepts of file permis¬ 
sions and ownership brings the discussion 
a step closer to the operating system. 
The examination of files ends with a 
chapter on directories, file systems, and 
special files. 


The sections on 
interprocessor 
communications, 
amounting to almost 100 
pages, are particularly 
good. 


Next, the authors present the library 
function calls to perform the operations 
being discussed, followed by code frag¬ 
ments in C that drive the concepts 
home. The code can be extracted and 
used; for example, a function to find an 
entry in a directory with a specified suf¬ 
fix is offered in its entirety. 

I am impressed by the concise, yet 
complete, discussion of the concepts 


involved. In about 15 pages, Haviland 
and Salama clearly present confirma¬ 
tion of the Unix file system that I had to 
glean from many other sources in eight 
years of work. Also, each chapter con¬ 
tains exercises to make you think and to 
test your understanding of the concepts 
presented. They could be used either as 
intellectual stimulation or coding 
exercises. 

The rest of the book deals with pro¬ 
cesses, interprocessor communication, 
terminal handling, the standard I/O 
library, and screen handling using the 
curses package. The final section briefly 
covers such easy concepts as memory 
management, string handling, and math 
functions. The appendix presents an 
explanation of the error codes returned 
by the standard library in “errno.” 

The book is up-to-date; the code con¬ 
forms to the standards presented in 
AT&T’s System V Interface Definition, 
Issue 2 (AT&T, 1986). 

The sections on interprocessor com¬ 
munications, amounting to almost 100 
pages, are particularly good. They start 
with an example of how you use inter¬ 
processor communications without 
thinking about it (interrupting an 
executing program) and expand to 
lucidly cover all the concepts. 

This book does an excellent job of 
tying all the Unix concepts together and 
showing how, in practical examples, to 
use these concepts to complete your 
task. The only similar work I am aware 
of is Marc J. Rochkind’s excellent 
book, Advanced Unix Programming 
(Prentice Hall, Englewood Cliffs, N.J., 
1985). However, Rochkind does not 
connect the concepts as well as 
Haviland and Salama do, and the age 
of the book prevents discussion of con¬ 
formation information related to the 
System V Interface Definition. 

I found no technical errors in the 
book. The organization is excellent, 
starting with a preface that outlines the 
foundation of the book, its contents, a 
list of necessary concepts, and even 
some exercises to assure you that you 
have the necessary prerequisites. I 
highly recommend it. 

Phil Hughes 

Specialized Systems Consultants 


Peopleware: Productive 
Projects and Teams 

Tom DeMarco and Timothy Lister 

(Dorset House Publishing Co., New 

York, 1987, 188 pp., $23, softcover) 

I am always skeptical about books 
with cute titles, especially when the 
cover carries numerous endorsements 
by “experts.” But if you are responsi¬ 
ble for managing the people who work 
on software development projects, this 
book, cutesy title and all, is certainly 
worth reading. The authors’ insight and 
experience will validate the apprehen¬ 
sions you’ve always had about meeting 
impossible deadlines. After you’ve read 
the book, you might also decide to leave 
it on the desk of your senior nontechni¬ 
cal manager. 

Peopleware is divided into five parts, 
each focusing on obvious, but mostly 
undocumented, critical issues related to 
hiring, managing, and retaining techni¬ 
cal personnel. 

As most of us know but rarely admit, 
we first became managers because we 
were good at getting things done—not 
because we knew how to be managers. 
We even less frequently admit that soon 
after that first promotion, we started to 
manage projects instead of people. 

Section I, “Managing the Human 
Resource,” tells us that most unsuccess¬ 
ful projects failed because of people 


Development projects 
can’t be managed like 
hamburger stands. 


problems, not technological problems. 
But development managers often spend 
their time on matters related to technol¬ 
ogy because it’s easier to do that than to 
deal with personnel issues. 

The authors state that development 
projects can’t be managed like ham¬ 
burger stands whose efficiency is meas¬ 
urable in terms of hourly hamburger 
output. You can’t coerce developers to 
be inventive, creative, and thoughtful. 

If you try, overworked people will pro- 
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duce low-quality products or simply 
leave the company. 

Interestingly, the authors’ extensive 
experience indicates that workers who 
are allowed to spend more time improv¬ 
ing the quality of a product generally 
are proud of their work (and the com¬ 
pany) and tend to be more productive. 
But allowing developers to fine-tune 
their work often seems to conflict 
directly with company schedules. 

Part II discusses an issue over which 
most individual managers have no 
control—the physical space in which 
their people work. It is useful to know 
that studies have shown a relationship 
between productivity and the quality of 
the workplace. For example, reducing 
the work space cost per employee 
(usually producing noisier and less com¬ 
fortable work environments) has a quan¬ 
tifiable negative effect on productivity— 
something you as a manager might 
include in a plea for better working con¬ 
ditions for your project team. Also, the 
telephone is justifiably vilified as a key 
productivity-reducing villain in most 
offices. 

Part III, entitled “The Right Peo¬ 
ple,” presents hints and tips on inter¬ 
viewing, hiring, and keeping 
high-quality employees. The authors 
provide sage advice concerning the 
benefits to the company and to product 
quality when company loyalty is 
fostered among employees. 

Part IV, “Growing Productive 
Teams,” describes a phenomenon well 
understood by the manager in the 
trenches, but seemingly beyond the 
comprehension of senior managers, 
whose eyes are on loftier strategic 
issues. Successful projects are usually 
the result of “jelled” teams. But cor¬ 
porate goals can rarely serve as the cata¬ 
lyst to effect the jelling. Teamwork can 
be inspired by setting goals that are 
meaningful to the project team mem¬ 
bers themselves. (Often these goals are 
related to the specifics of the project 
itself, rather than to more remote objec¬ 
tives related, perhaps, to annual board 
meetings.) 

The title of Part V says much about 
an ambiance often deliberately elimi¬ 
nated out of budgets and schedule¬ 
conscious high-tech development envi¬ 
ronments: “It’s Supposed to Be Fun to 
Work Here!” 

It’s too bad you can’t tie your com¬ 
pany president, CEO, or CFO to a chair 
and read this book to him/her. If you 
survived the experience, your life would 
probably be a lot easier afterward. 

Sorel Reisman 

California State University, Fullerton 


Manufacturing Intelligence 


Paul Kenneth Wright and David 
Alan Bourne (Addison-Wesley Pub¬ 
lishing Co., Reading, Mass., 1988, 
352 pp., $37.95) 

This book examines the growing 
involvement of computer science in the 
manufacturing sciences. It would be 
especially helpful for computer profes¬ 
sionals who need to understand the 
procedures and problems of artificial 
intelligence in the factory. The applica¬ 
tion of computer technology to the 
solution of these problems requires 
expertise from both fields. 

The book explores current practices 
in automated manufacturing and cur¬ 
rent research that could lead to new fac¬ 
tory procedures. It contains an excellent 
glossary for those unfamiliar with man¬ 
ufacturing terminology and an excellent 
bibliography for those who wish to pur¬ 
sue further topics. 

The book is divided into four parts. 
The first part introduces terminology 
and provides a framework for those 
who are new to the manufacturing envi¬ 
ronment. It also contains a survey of 
existing systems in flexible manufactur¬ 
ing, including ISIS, a job-shop schedul¬ 
ing system; CML, a cell-manufacturing 
language for linking multivendor equip¬ 
ment; and other current CNC machin¬ 
ing centers. 


The second part includes an examina¬ 
tion of underlying principles that can be 
used to build intelligent machines, such 
as certain components of software 
architecture. Vision techniques and part 
manipulation in this environment are 
also examined. 

Part three contains a case study of a 
manufacturing operation, including a 
discussion of the machinist’s skills and 
a proposed procedure for abstracting 
the machinist’s knowledge for inclusion 
in an expert system. The authors exam¬ 
ine setup plans in great detail and 
emphasize the need for more research in 
this area. 

Part four looks to the future and 
examines research opportunities and 
achievements possible over the next 30 
years. 

1 would not recommend this book as 
a text in this emerging field. It contains 
far more questions than answers, but 
that is the state-of-the-field at this time. 
However, I have found this book useful 
in establishing a reading competence in 
the manufacturing area as well as form¬ 
ing an idea of future trends. The 
authors have made a beginning in an 
important area of computing. 

Guy Johnson 

Rochester Institute of Technology 


Chaos: Making a New Science 


James Gleick (Viking Press, New 

York, 1987, 352 pp., $19.95) 

In 1960, Edward Lorenz was running 
an atmospheric simulation on his small 
vacuum-tube computer as part of his 
research in meteorology and weather 
forecasting. Due to the limited capacity 
of his machine, his simulation model 
consisted of only a few simple equa¬ 
tions. As the simulation ran, it printed 
the new results for each time step in a 
slow, tedious process. 

One day, after interrupting the simu¬ 
lation, Lorenz decided to restart it by 
simply entering the printed values from 
an earlier time step. He entered the 
values using fewer significant digits 
than were stored in the machine, assum¬ 
ing that the slight difference would have 
no effect on the outcome of his “well- 
behaved” system of equations. 

After a relatively small number of 
steps, however, he noticed that his out¬ 
put was beginning to diverge greatly 
from that of a previous run. Lorenz 


realized that he might have discovered 
something more interesting than he 
could explain by simple round-off 

With this anecdote, James Gleick 
introduces the reader to the idea of 
“sensitive dependence on initial condi¬ 
tions.” Engineers accustomed to work¬ 
ing with linear systems typically assume 
that choosing arbitrary initial condi¬ 
tions will cause the system to converge 
to the same steady-state after sufficient 
time has passed. Unfortunately, the 
world is not linear, and often times it is 
not sufficient to model systems with 
simple linear equations. In many cases, 
nonlinear equations are required. These 
equations look quite simple but often 
have surprising properties. 

One of the revolutionary discoveries 
described in the book is the fact that 
many simple nonlinear systems can 
exhibit very complex behavior with only 
minor perturbations in initial conditions 
or system parameters. This is called the 
“butterfly effect,” alluding to the idea 
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that atmospheric disturbances caused 
by a butterfly in China today could 
potentially have an enormous impact on 
the weather in New York next month. 

As scientists began to examine the 
peculiarities of these “chaotic” non¬ 
linear systems, it became apparent that 
a new geometry was required to under¬ 
stand their significance. Benoit Mandel¬ 
brot is credited with providing this new 
view with his fractal geometry—a 
geometry with fractional dimensions 
that provides a consistent framework, 
from the galactic scale of the 
astronomer to the microscopic scale of 
the chemist. Gleick does a wonderful 
job of giving the reader a feel for Man¬ 
delbrot’s intellectual abilities and 
insights, as well as the public relations 
abilities he skillfully used to spread his 
ideas. There were some scientists, how¬ 
ever, who were not ready to accept 
Mandelbrot’s ideas. 

Using the “Dynamical Systems Col¬ 
lective” at the University of California 
at Santa Cruz, as an example, Gleick 
shows how the scientific establishment 
was reluctant to accept some of the 
other ideas in the developing science of 
chaos. The collective was a group of 
physics graduate students who 
“dropped out” of their department’s 
mainstream to pursue ideas about chaos 
and complex system behavior. As 
described by Gleick, they supported 
themselves both financially and aca¬ 
demically; the professors in the depart¬ 
ment neither discouraged nor encouraged 
the collective. Through dedication and 
self-reliance, however, small groups of 
“believers,” such as this collective, 
spread the word about the possibilities 
of chaos. 

After many hours of interviewing and 
researching the main players in this new 
field, Gleick has crafted an enjoyable 
book that contains several interweaving 
themes. In addition to its introduction 
of the main participants in the field, the 
book offers a nontechnical introduction 
to the ideas and concepts of chaos. As 
summarized by Gleick, the science of 
chaos involves the realization that sim¬ 
ple systems can exhibit surprisingly 
complex behavior, and that complex 
systems can often be accurately 
described by surprisingly simple 
models. This new paradigm moves from 
the conventional scientific reductionist 
way of thinking to a more holistic 
approach, where the system is seen as 
more than the sum of its parts. The 
author presents many examples from 
several disciplines to reinforce his point. 

Gleick also provides a fascinating 
look at how a new way of thinking 
works its way into the methods of 


established science. He shows that some 
people ignore the new ideas because 
they are too unsettling, misunderstood, 
or too far removed from the status quo, 
while others embrace the new potential 
avenues of research and techniques for 
understanding the dynamics of complex 
systems. Gleick states that one ecologist 


Program Construction 

R.G. Stone and D.J. Cooke (Cam¬ 
bridge University Press, New York, 

1987, 372 pp„ $49.50) 

Despite two decades of intense atten¬ 
tion from researchers, the production 
of certifiable software under industrial 
conditions remains a formidable chal¬ 
lenge. It seems as though there won’t be 
any breakthroughs—only painstaking 
progress. 

Program Construction is designed to 
contribute to this progress. The authors 
state that “this text promotes the dis¬ 
ciplined construction of procedural pro¬ 
grams from formal specifications.” 
However, this can be said of just about 
any book on the topic. The book is best 
characterized by the following features: 

• It is based on a formal description 
of specifications by pairs of predicates 
(rather than by functions or by 
relations). 

• It deals with imperative target lan¬ 
guages (Cobol, Pascal, Fortran, 
assembly). 

• It concentrates primarily on the 
algorithmic (that is, control structure) 
aspects of program construction rather 
than the data structure aspects, 
although abstract data types receive 
some attention. 

• As a fairly logical consequence of 
the above feature, it uses a PDL-style 
design notation to record design deci¬ 
sions between the specification and the 
target programming languages. 

• It discusses—though secondarily— 
the specification and implementation of 
abstract data types. 

The authors outline their approach to 
the material in Chapter 1. Then, in 
Chapters 2 and 4, they discuss specifica¬ 
tions. It is not clear why the authors 
interrupt their study of specifications 
with the discussion of diagrams in 
Chapter 3, nor why they should discuss 
diagrams at all. Chapter 5 covers design 
and contains a thorough description of 
PDL. 

Chapters 6 and 8 discuss how to map 
PDL descriptions into actual code. The 


who started using the ideas of chaos 
“could not work the old way any 
more.” This book does a fine job of 
explaining why. 

David J. Lilja 

University of Illinois, Urbana- 

Champaign 


chapters are thorough, detailed, and 
practical. But in the middle of discuss¬ 
ing code generation, the authors veer 
off into an examination of verification 
rules in Chapter 7. This reviewer sees 
four better locations for this chapter: 

• outside the book, since program 
verification is a prerequisite for pro¬ 
gram construction; 

• following the study of specifica¬ 
tions, since correctness is the property 
we want to realize between a program 
and a specification; 

• following the study of PDL, since 
program correctness formulas can be 
used to check the coherence of a PDL 
design with respect to a specification; or 

• following the study of code genera¬ 
tion, as a means to check the correct¬ 
ness of the final program against the 
initial specification. 

Chapters 9 and 10 cover the specifica¬ 
tion and implementation of abstract 
data types, Chapter 11 discusses the 
reuse of programs, and Chapter 12 
presents a small case study of program 
construction. The bibliography is brief, 
and several standard references are 
missing. 

The authors do not intend this book 
to be a main text for a course. They 
propose its use in conjunction with 
other books on algorithm design. As 
such, it could be used in a second or 
third programming course on the 
undergraduate level. The book’s prereq¬ 
uisites are fairly basic, since the 
mathematics used are mostly simple set 
theory and logic. Also, the book can be 
useful as a reference work for the prac¬ 
ticing programmer. 

Program Construction suffers from a 
lack of cohesion among the chapters 
and the absence of an integrated meth¬ 
odology covering the whole program¬ 
ming process from specification to 
coding. The book’s main strengths are 
its concern for practical aspects of pro¬ 
gramming and its thoroughness in 
presenting useful tools to the practicing 
programmer. 

Ali Mili 

University of Tunis II, Tunisia 
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NEW LITERATURE 


Understanding MAP: Manufacturing 
Automation Protocol , edited by Victor 
A. Rizzardi, offers 25 articles describ¬ 
ing the concepts, principles, and appli¬ 
cations that permit integration of MAP 
production equipment made by differ¬ 
ent vendors. The ISO seven-layer sys¬ 
tem that forms the basis of the MAP 
specification for computer communica¬ 
tion is examined, along with hardware 
required and media used. A MAP, 

TOP, and LAN glossary that defines 
more than 150 terms is included. 

The book is available for $37 through 
Amy Hartzer, Society of Manufactur¬ 
ing Engineers, One SME Drive, PO Box 
930, Dearborn, MI 48121. The book is 
$29 to SME members. 

The Handbook of Communications 
Systems Management (ISBN 
0-88712-505-0, approx. 1,000 pp., $88) 
is designed to address the challenges 
faced by MIS and communications 
managers and their staffs when 


selecting, implementing, and maintain¬ 
ing data communications systems. Edi¬ 
tor James W. Conard has collected 
more than 75 articles examining such 
topics as strategic planning, selecting 
hardware and software, staffing, secu¬ 
rity, and end-user computing. The book 
includes guides, checklists, outlines, 
lists of objectives, and a procedural 
orientation. Contact Auerbach Pub¬ 
lishers, One Penn Plaza, New York, NY 
10119. 


Fault-tolerant computing. Springer- 
Verlag has published Dependable Com¬ 
puting and Fault-Tolerant Systems, 

Vol. 1: The Evolution of Fault-Tolerant 
Computing (ISBN 3-211-81941-X, 480 
pp.) and Vol. 2: Software Diversity in 
Computerized Control Systems (ISBN 
3-211-82014-0, 216 pp.). The first vol¬ 
ume, edited by A. Avizienis, H. Kopetz, 
and J.C. Laprie, covers the evolution, 
state of the art, and future perspectives 


in fault-tolerant computing. The papers 
were originally presented at a sympo¬ 
sium in Baden, Austria, on June 30, 
1986. The second volume was edited by 
U. Voges. Contact Springer-Verlag, 
Molkerbastei 5, PO Box 367, A-1011 
Wien, Austria. 


Ultimate Computing (ISBN 
0-444-70283-0, 358 pp.) by S.R. 
Hameroff is an anesthesiologist’s view 
of the coevolution of consciousness and 
technology. Hameroff advances the 
premise that the cytoskeleton is the ner¬ 
vous system of the biological cell, and 
that emerging “nanotechnologies” such 
as scanning tunneling microscopy, 
Feynman machines, and von Neumann 
replicators should enable monitoring, 
decoding, and interfacing between bio¬ 
logical and technological information 
devices. Contact Elsevier Science Pub¬ 
lishing Co., PO Box 1663, Grand Cen¬ 
tral Station, New York, NY 10163. 


New and Recent Titles from Academic Press 

Design Automation 

Automated Full-Custom VLSI Layout Using the 
ULYSSES Design Environment 

Michael L. Bushnell 

ULYSSES is a VLSI computer-aided design environment that 
effectively addresses the problems associated with CAD tool 
integration. It allows for the integration of a collection of 
individual CAD tools into a design automation system that will 
execute a codified design methodology. 

The design environment employs artificial intelligence 
techniques and functions as an interactive expert system. 

May 1988, 482 pp. $44.50 Casebound/ISBN 0-12-148400-9 

Mechanisms for Reliable Distributed 
Real-Time Operating Systems 

The Alpha Kernel 

J. Duane Northcutt 

This book documents a set of kernel-level mechanisms that 
support the construction of modular, reliable, decentralized 
operating systems for real-time control applications. The major 
contributions extend from programming abstractions and an 
operating system kernel interface through the detailed 
engineering tradeoffs required to create, implement, and 
cleanly integrate the internal mechanisms. 

1987, 250 pp. $25.00 Casebound/ISBN 0-12-521690-4 

Desktop Video 

A Guide to Personal and Small Business Video 
Production 

Austin H. Speed III 

The author shares his experience in this new field as he 
discusses desktop video production equipment and software 
as well as the principles involved in their development. 

Harcourt Brace Jovanovich, Publishers 

May 1988, 250 pp. $14.95 Paperback/Order Code 311614 

IBM — The Making of the Common View 
Michael Killen 

"IBM — The Making of the Common View is required reading 
for anyone who wants to be successful in dealing with IBM. 

Killen's well-researched story has the educational value of a 

Harvard Business School case-study while being entertaining 
at the same time.”— George Fullerton, Vice President, 
Marketing/Sales, MAD Intelligence Systems, Inc. 

Harcourt Brace Jovanovich, Publishers 

April 1988, 304 pp. $17.95 Casebound/Order Code 311615 
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THE COMPUTER SOCIETY 

A member society of the Institute of Electrical and Electronics Engineers, Inc. 


Executive Committee 

President: Edward A. Parrish, Jr* 

Vanderbilt University 
School of Engineering 
Nashville, TN 37235 
(615) 322-2762 

President-Elect: Kenneth R. Anderson* 

Vice Presidents 

Standards: Helen M. Wood (1st VP)* 
Conferences and Tutorials: Joseph E. Urban (2nd VP)* 
Area Activities: Willis Kingt 
Education: Gerald L. Engelt 
Membership and Information: Merlin G. Smitht 
Publications: James H. Aylort 
Technical Activities: Laurel V. Kaleda 
Secretary: Duncan H. Lawrie 
Treasurer: Barry W. Johnsonf 
Past President: Roy L. Russo* 

Division V Director: Harriett Rigast 
Division VIII Director: H. Troy Nagle, Jr.f 
Executive Director: T. Michael Elliottt 

'voting member of the Board of Governors 


Board of Governors 
Term Ending 1988 

Mario Barbacci 
Victor Basili 
Paul Borrill 
Lorraine M. Duvall 
Michael Evangelist 
Allen L. Hankinson 
Laurel V. Kaleda 
Ted Lewis 
Ming T. Liu 

Earl E. Swartzlander, Jr. 

Next Board Meeting 

June 17,1988—8:30 a.m. 

Anaheim Sheraton, Anaheim, CA 

Senior Staff 

Executive Director: T. Michael Elliott 
Editor and Publisher: True Seaborn 
Director, Computer Society Press: Chip G. Stockton 
Director, Conferences: Anne Marie Kelly 
Director, Finance and Administration: Mary Ellen Curto 

Computer Society Offices 

Headquarters Office 

1730 Massachusetts Ave. NW 
Washington, DC 20036-1903 
Phone: (202) 371-0101 
Telex: 7108250437 IEEE COMPSO 
Publications Office 
10662 Los Vaqueros Circle 
Los Alamitos, CA 90720 

Membership and General Information: (714) 821-8380 
Publications Orders: (800) 272-6657 
European Office 
13, Avenue de I’Aquilon 
B-1200 Brussels, Belgium 
Phone: 32 (2) 770-21-98 
Telex: 25387 AVVALB 


Term Ending 1989 

Bill D. Carroll 
Lansing Hatfield 
Duncan H. Lawrie 
David Pessel 
Susan L. Rosenbaum 
Sal lie V. Sheppard 
Bruce D. Shriver 
Harold S. Stone 
Akihiko Yamada 
Marshall C. Yovits 


Use the Reader Service Card to obtain the following 
information: 

• Membership application—student #203, others #202 

• Periodicals subscription form for individuals #200 

• Periodicals subscription form for organizations #199 

• Publications catalog #201 

• Standards working groups list #195 

• COMPMAIL+ international electronic mail/database 
brochure #194 

• Technical committee list/application #197 

• Chapters lists, start-up procedures—student/regular 
#193 

• Student scholarship information #192 

• Awards description/nomination forms #198 

• Volunteer leaders/staff directory #196 

• IEEE senior member application #204 


The Computer Society advances the theory and practice of computer 
science and engineering, promotes the exchange of technical 
information among 90,000 members worldwide, and provides a 
wide range of services to members and nonmembers. 

Membership 

Members receive the acclaimed monthly magazine Computer, 
discounts, and opportunities to serve (all activities are led by 
volunteer members). Membership is open to all IEEE members, 
affiliate society members, and others seriously interested in the 
computer field. 

Publications and Activities 

Computer. An authoritative, easy-to-read magazine containing 
tutorial and in-depth articles on topics across the computer field; 
plus news, conferences, calendar, interviews, new products, etc. 

Periodicals. The society publishes six magazines and three 
research transactions. Refer to membership application or request 
information as noted above. 

Conference Proceedings, Tutorial Texts, Stahdards Documents. 

The Computer Society Press publishes more than 100 titles every 
year. 

Standards Working Groups. Over 100 of these groups produce 
IEEE standards used throughout the industrial world. 

Technical Committees. Over30TCs provide newsletters, interac¬ 
tion with peers in specialty areas, and have direct influence on 
standards, conferences, education, etc. 

Conferences/Education. The society holds about 100 conferences 
each-year and sponsors many educational activities, including 
computing sciences accreditation. 

Chapters. Regular and student chapters worldwide provide the 
opportunity to interact with colleagues, hear technical experts, and 
serve the local professional community. 

European Office 

Payments for Computer Society membership and publication 
orders are accepted by cheques in Belgian, British, German, Swiss, 
or U.S. currency, or by American Express, Eurocard, MasterCard, or 
Visa credit cards. 

Ombudsman 

Members experiencing problems—magazine delivery, member¬ 
ship status, unresolved complaints—may write to the ombudsman 
at the Publications Office. 
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